Posts on Security, Cloud, DevOps, Citrix, VMware and others.
Words and views are my own and do not reflect on my companies views.
Disclaimer: some of the links on this site are affiliate links, if you click on them and make a purchase, I make a commission.
This ongoingDocker Labs GenAI seriesexplores the exciting space of AI developer tools. At Docker, we believe there is a vast scope to explore, openly and without the hype. We will share our explorations and collaborate with the developer community in real time. Although developers have adopted autocomplete tooling like GitHub Copilot and use chat, there is significant potential for AI tools to assist with more specific tasks and interfaces throughout the entire software lifecycle. Therefore, our exploration will be broad. We will be releasing software as open source so you can play, explore, and hack with us, too.
LLMs are now quite good at transforming data. For example, we were recently working with some data generated by the Pylint tool. This tool generates big arrays of code violations.
Here’s an example showing the kind of data that gets returned.
During this session with our AI assistant, we decided that it would be helpful to create a database and insert the data to make it easier for the AI to analyze (LLMs are very good at writing SQL). As is now our habit, we wrote a quick prompt to see if the assistant could generate the SQL:
1. Read the json data from /thread/violations.json
2. For each element in the array, transform each element into two SQL INSERT statements.
* The first should insert columns PATH, START_LINE, END_LINE, START_COLUMN, END_COLUMN into a table named RANGES.
* The second should insert columns MESSAGE, TYPE, RANGE, and VIOLATION_ID into a table named VIOLATIONS.
LLMs are obviously good at tasks of this kind, and this was no exception. Our prompt engine had been augmented with a function to read local files but, besides that, this was a pretty straightforward prompt (we used GPT-3.5). The LLM responded with the correct INSERT statements.
INSERT INTO RANGES (PATH, START_LINE, END_LINE, START_COLUMN, END_COLUMN)
VALUES ('src/app.py', 1, 1, 0, 13);
INSERT INTO VIOLATIONS (MESSAGE, TYPE, RANGE, VIOLATION_ID)
VALUES ('Missing module docstring', 'convention', (SELECT ID FROM RANGES WHERE PATH='src/app.py' AND START_LINE=1 AND START_COLUMN=0), 'C0114');
...
...
We’re starting to get accustomed to this kind of capability, so the result wasn’t too surprising. However, what about the context window here? It really doesn’t make a lot of sense to pass all of this data to the LLM, especially if this is a task that we’ll need to do continuously. Plus, this is really not how a programmer would have solved the problem.
Programmers would write programs.
So, instead of asking the LLM to do a thing, we should try asking it to write a program to do that same thing. Starting with the same prompt, let’s prefix it with “Please write a JavaScript program to …” In other words, let’s ask the LLM to describe how it would accomplish the task in JavaScript, and hopefully automate itself out of the loop. Here’s the adjusted prompt:
Write a javascript function that reads json from a file named `/thread/violations.json`.
For each element in the array, transform each element into two SQL INSERT statements.
* The first should insert columns PATH, START_LINE, END_LINE, START_COLUMN, END_COLUMN into a table named RANGES.
* The second should insert columns MESSAGE, TYPE, RANGE, and VIOLATION_ID into a table named VIOLATIONS.
and write them to the file /thread/insert.sql
Now execute the javascript code in a container.
Tool code
Current LLMs can do tasks of this kind. Here’s a sample of the output generated by GPT-3.5. A quick scan will convince many of you that this is probably going to do the trick. However, if our prompt engine is already running in Docker, we might as well just run it:
const fs = require('fs');
const crypto = require('crypto');
function getRandomId() {
return crypto.randomBytes(16).toString('hex');
}
function escapeString(str) {
return str.replace(/'/g, \\\"''\\\");
}
let data = JSON.parse(fs.readFileSync('/thread/violations.json', 'utf8'));
let sqlStatements = '';
data.forEach((violation) => {
let id = getRandomId();
sqlStatements += `INSERT INTO RANGES(ID, PATH, START_LINE, END_LINE, START_COLUMN, END_COLUMN) VALUES('${id}', '${escapeString(violation.path)}', ${violation.line}, ${violation.endLine}, ${violation.column}, ${violation.endColumn});\\\\n`;
sqlStatements += `INSERT INTO VIOLATIONS(MESSAGE, TYPE, RANGE) VALUES('${escapeString(violation.message)}', '${escapeString(violation.type)}', '${id}');\\\\n`;
});
fs.writeFileSync('/thread/insert.sql', sqlStatements);
Running the tool
You may not have noticed but at the end of our prompt, we added a final instruction: “Now execute the JavaScript code in a container”. This is a nice addition to our session, because it means we get to see the results.
This is also where tool calling comes back into the picture. To give our AI the capacity to try running the program that it has just written, we have defined a new function to create an isolated runtime sandbox for trying out our new tool.
Here’s the agent’s new tool definition:
tools:
- name: run-javascript-sandbox
description: execute javascript code in a container
parameters:
type: object
properties:
javascript:
type: string
description: the javascript code to run
container:
image: vonwig/javascript-runner
command:
- ""
We’ve asked the AI assistant to generate a tool from a description of that tool. As long as the description of the tools doesn’t change, the workflow won’t have to go back to the AI to ask it to build a new tool version.
The role of Docker in this pattern is to create the sandbox for this code to run. This function really doesn’t need much of a runtime, so we give it a pretty small sandbox.
No access to a network.
No access to the host file system (does have access to isolated volumes for sharing data between tools).
No access to GPU.
Almost no access to software besides the Node.js runtime (no shell for example).
The ability for one tool to create another tool is not just a trick. It has very practical implications for the kinds of workflows that we can build up because it gives us a way for us to control the volume of data sent to LLMs, and it gives the assistant a way to “automate” itself out of the loop.
Next steps
This example was a bit abstract but in our next post, we will describe the practical scenarios that have driven us to look at this idea of prompts generating new tools. Most of the workflows we’re exploring are still just off-the-shelf tools like Pylint, SQLite, and tree_sitter (which we embed using Docker, of course!). For example:
Use pylint to extract violations from my codebase.
Transform the violations into SQL and then send that to a new SQLite.
Find the most common violations of type error and show me the top level code blocks containing them.
However, you’ll also see that part of being able to author workflows of this kind is being able to recognize when you just need to add a custom tool to the mix.
With the launch of the Citrix platform this year, we’re working towards building a better Citrix for you. This means integrating more capabilities, adding more automation, and adding more to your Citrix entitlements so you get more out of your Citrix solution. You have access to more Citrix than ever before, includingon-demand trainingand XenServer 8 entitlements.
In this webinar, we’ll go over some of the many new features we have added to your Citrix entitlements this year to support new use cases, simplify management, and increase security. If you’re ready to learn more about what’s included in your Citrix entitlements, how to maximize your environment, and how to implement new features,registerfor our latest webinar on October 30th.
What’s new with Citrix solutions
In this webinar, we’ll cover updates to XenServer, Citrix Secure Private Access, Citrix Enterprise Browser, and Citrix Virtual Apps and Desktops including:
XenServer
XenServer 8 release and new features like support for Windows 11, a Terraform Provider, new monitoring capabilities, and more
Continuous security enforcement and data leakage prevention
Unified Secure Access with IGEL OS and client integration
New features in Citrix Enterprise Browser
Citrix Virtual Apps and Desktops
The Citrix Virtual Apps and Desktops 2402 LTSR Cumulative Update enhancements and top LTSR features
How to leverage the Citrix Terraform Provider and Citrix Automated Configuration Tool for easier site-to-site migrations and in-place upgrades
We’ll also have a live Q&A with Citrix product experts to answer your most pressing Citrix questions.
Register today
Make sure you’re making the most out of your Citrix entitlement. Join our webinar to hear more about what’s new with Citrix and learn how you can leverage these new features in your environment to simplify management, increase security, and more.Register todayto save your spot!
from Citrix Blogs https://ift.tt/oUb4ipF
via IFTTT
PinnacleOne ExecBrief | Are You Actuarially In Good Hands?
Cyber insurance has matured as a product over the last few years, but large uncertainties remain around what the industry terms the “aggregation risk” of “systemic events” associated with state-directed cyber attacks. These events, driven by state actors or affiliates, pose significant challenges for insurers, as the potential for widespread disruption across multiple sectors and regions creates a risk that is difficult to measure, predict, and mitigate.
Published in August 2022 on the heels of Russia’s invasion of Ukraine, Lloyd’s Market Bulletin Y5381 introduced a significant shift in cyberattack insurance policies, mandating exclusions for state-backed cyberattacks starting from March 2023. These policies were required to rule out coverage for cyberattacks tied to government actions unless explicitly agreed otherwise. Lloyd’s wrote at the time:
“If not managed properly it [a state-backed cyberattack] has the potential to expose the market to systemic risks that syndicates could struggle to manage. In particular, the ability of hostile actors to easily disseminate an attack, the ability for harmful code to spread, and the critical dependency that societies have on their IT infrastructure, including to operate physical assets, means that losses have the potential to greatly exceed what the insurance market is able to absorb.”
The exclusions applied to cyberattacks that disrupted essential state functions or security, and insurers had to create clear processes to attribute these attacks to specific states. While the move aligned Lloyd’s with major players like Munich Re, it created potential conflicts with non-Lloyd’s insurers and raised concerns about gaps in coverage.
Sample Cyber War Exclusion Clause Suggested by Lloyd’s Market Association (Source)
By January 2024, the gravity of these exclusions was underscored by a congressional hearing on the Volt Typhoon, a Chinese hacking operation. U.S. cyber authorities warned of China’s plans to target critical infrastructure in the event of armed conflict to deter American military engagement. The People’s Republic of China (PRC) believes that disrupting civilian infrastructure could dissuade both U.S. leaders and the public from supporting military action. This threat is especially concerning as most critical infrastructure in the U.S. is privately owned, with operators resisting government regulation.
Even after the release of National Security Memorandum-22, which sought to boost critical infrastructure security, the government’s ability to enforce meaningful change was limited. Federal purchasing requirements were the only leverage to encourage compliance with minimum security standards.
Despite some infrastructure operators ignoring government warnings, insurers were acutely aware of the risks. With billions of dollars at stake, insurance companies closely followed the developments in state-backed cyber threats, particularly from China. Lloyd’s 2022 policy changes — excluding state-backed cyberattacks from coverage — became even more relevant as companies faced growing risks from global cyber warfare.
As these cyber threats have intensified, disputes over attribution, vague terms like “major detrimental impact,” and the broad language of exclusions remain significant issues. This has put the onus on businesses to reevaluate their cyber defenses and insurance policies, as insurers moved to protect themselves from the potentially devastating costs of a state-backed cyberattack.
A recent report by a cyber insurer noted that while “worst-case scenarios have not yet come to pass…risks associated with cyber warfare and systemic events more generally – scenarios where single attacks trigger widespread failures across multiple organizations – remain a concern.” They flagged that “the risk of and uncertainty around aggregation continues to hang over the market by impeding capital inflows and tempering risk appetite.”
Attribution is Key
The main issue likely to cause disputes between insurers and policyholders is the attribution of cyberattacks. Determining whether a cyber operation occurred, based on “objectively reasonable evidence,” is often contentious. The process for establishing sufficient evidence is unclear, and the covert nature of cyberattacks makes it difficult to determine state responsibility. States may use third parties, like cybercriminal groups, to conduct attacks, further obscuring the source.
Even when a state attributes a cyberattack to another, this information might not be publicly disclosed due to political or diplomatic sensitivities. A state could withhold attribution if releasing it would have significant financial consequences for insured businesses. Moreover, a state may attribute an attack based on political motivations rather than hard evidence, which can complicate the situation. It is also unclear whether attribution must come from the executive or legislative branch, or whether statements from intelligence or military agencies suffice.
Additionally, the definition of “major detrimental impact” remains vague, which could lead to disagreements over what qualifies as significant disruption. The broad language of the exclusion clauses, covering both direct and indirect losses, may limit coverage substantially depending on the event. This raises questions about whether the Lloyd’s model clauses adequately meet the requirement to provide a clear and robust attribution process and clearly define key terms. Given these ambiguities, careful review of cyber policy wordings is crucial to reduce the risk of disputes over cyberattack claims.
There are a number of variants of such clauses that offer different exclusions based on different attribution requirements and scope of coverage. The devil is truly in the details here…
Cyber War Clauses That Meet Lloyd’s Requirements Have Different Exclusions and Attribution Requirements (Source)
Risk Lurking in the Tails
Attacks like those seen in the SolarWinds and Microsoft compromises illustrate how state-directed cyber operations can have far-reaching effects, crossing borders and impacting a wide array of industries. The recent MOVEit, Change Healthcare and NHS incidents showed how attacks on a single critical software, firm, or government service can cascade across the economy, creating systemic aggregate losses.
As insurers step away from covering cyber warfare-related risks, the question of responsibility looms. With the federal government acknowledging that it cannot effectively deter state-backed cyber intrusions, businesses are increasingly left in a precarious position. Top agency officials from both the NSA and FBI have admitted the grim reality: China, one of the leading perpetrators of cyber operations, cannot be deterred from targeting U.S. critical infrastructure.
Businesses must now contend with a new reality where neither governments nor insurers can fully shield or cover them from nation-state attacks. It’s up to private firms to understand and own this risk and put in place sufficient security measures to defend themselves.
Organizations are losing between $94 - $186 billion annually to vulnerable or insecure APIs (Application Programming Interfaces) and automated abuse by bots. That's according to The Economic Impact of API and Bot Attacks report from Imperva, a Thales company. The report highlights that these security threats account for up to 11.8% of global cyber events and losses, emphasizing the escalating risks they pose to businesses worldwide.
Drawing on a comprehensive study conducted by the Marsh McLennan Cyber Risk Intelligence Center, the report analyzes over 161,000 unique cybersecurity incidents. The findings demonstrate a concerning trend: the threats posed by vulnerable or insecure APIs and automated abuse by bots are increasingly interconnected and prevalent. Imperva warns that failing to address security risks associated with these threats could lead to substantial financial and reputational damage.
API Adoption and the Expanding Attack Surface
APIs have become indispensable to modern business operations, enabling seamless communication and data exchange across applications and services. They power everything from mobile applications to eCommerce platforms and open banking. However, their widespread adoption has created significant security challenges. According to data from Imperva Threat Research, the average enterprise managed 613 API endpoints in production last year, and that number is projected to grow as companies rely more heavily on APIs to drive digital transformation and innovation.
This heightened reliance on APIs has dramatically expanded the attack surface, with API-related security incidents increasing by 40% in 2022 and an additional 9% in 2023. These attacks are particularly dangerous because APIs often serve as direct pathways to an organization's underlying infrastructure and sensitive data. The report estimates that API insecurity is responsible for up to $87 billion in annual losses, a $12 billion increase from 2021. This can be attributed to a variety of reasons, including the rapid adoption of APIs, inexperience of many API developers, lack of standardized security practices, and limited collaboration between development and security teams.
Bot Attacks: A Persistent and Evolving Threat
Alongside the rise in attacks on APIs, bot attacks have become a widespread and costly threat, resulting in up to $116 billion in losses annually. Bots—automated software programs designed to perform specific tasks—are frequently weaponized for malicious activities such as credential stuffing, web scraping, online fraud, and distributed denial-of-service (DDoS) attacks.
In 2022, security incidents related to bots surged by 88%, followed by an additional 28% increase in 2023. This alarming growth was fueled by a combination of factors, including the rise in digital transactions, proliferation of APIs, and geopolitical tensions such as the Russia-Ukraine conflict. The widespread availability of attack tools and generative AI models has also significantly enhanced bot evasion techniques and enabled even low-skilled attackers to carry out sophisticated bot attacks.
According to Imperva, bots now represent one of the most critical threats to API security. Last year, 30% of all API attacks were driven by automated threats, with 17% specifically tied to bots exploiting business logic vulnerabilities. The growing reliance on APIs—and their direct access to sensitive data—has made them prime targets for bot operators. Automated API abuse alone is now costing businesses up to $17.9 billion annually. As bots become more sophisticated, attackers are increasingly using them to exploit API business logic, bypass security measures, and exfiltrate sensitive data, making detection and mitigation more challenging for organizations.
Large Enterprises at Greater Risk
Large enterprises, especially those with annual revenues exceeding $1 billion, face a disproportionately higher risk of API and bot attacks. According to the report, these organizations are 2-3 times more likely to experience automated API abuse by bots compared to small or mid-size businesses. This heightened exposure is primarily driven by the complexity and scale of their digital infrastructures.
These companies typically manage hundreds or even thousands of APIs across multiple departments and services, creating sprawling API ecosystems that are challenging to monitor and secure. Within such environments, shadow APIs, unauthenticated APIs, and deprecated APIs present significant vulnerabilities. These mismanaged APIs often lack critical security measures, such as regular updates, authentication, and continuous monitoring, leaving them open to exploitation.
Similarly, large enterprises are prime targets for bot attacks due to their extensive digital presence and valuable assets. The more complex the digital environment, the more potential entry points exist for bots to exploit, ranging from login pages to checkout systems. With vast amounts of sensitive data flowing through their applications and APIs, these companies are a highly lucrative target for bot operators.
The risk is even more pronounced for enterprises with annual revenues exceeding $100 billion, where API insecurity and bot attacks account for as much as 26% of all security incidents. This stark figure highlights the critical need for comprehensive API security and bot management strategies in large enterprises, where a security incident can result in significant operational disruptions, substantial financial losses, and long-lasting reputational damage.
Protecting Against API and Bot Attacks
Together, vulnerable or insecure APIs and automated abuse by bots account for billions of dollars in annual losses. As businesses increasingly rely on APIs to power digital transformation, the risk of security incidents is expected to rise, putting organizations at greater risk of financial and reputational damage. Simultaneously, the evolution of bots, often driven by generative AI, has amplified the challenges of defending against these threats.
To effectively mitigate these risks, Imperva recommends that organizations take the following proactive steps:
Foster cross-functional collaboration: Collaboration between security and development teams is essential for embedding security into every stage of the API lifecycle. This partnership ensures that security measures are integrated from design to deployment, enabling proactive identification and mitigation of vulnerabilities before they can be exploited. When it comes to bot management, this collaboration must extend even further. Bots are a cross-functional challenge that impacts many areas of the business. To effectively combat them, teams across marketing, eCommerce, customer experience, IT, Line of Business, and security must work closely together. This broader collaboration helps identify vulnerable features, such as login pages, checkout processes, and forms, that are particularly susceptible to bot attacks.
Comprehensive API discovery and monitoring: Organizations must have full visibility into all their APIs, including shadow, deprecated, and unauthenticated APIs, to ensure none are overlooked. Continuous monitoring and auditing are essential to identifying potential vulnerabilities before they are exploited.
Integrate API security and bot management: Bot management and API security must be used in tandem to successfully mitigate automated attacks on API libraries. This combined approach helps identify vulnerable APIs, continuously monitors for automated attacks, and provides actionable insights for rapid detection and response. By integrating bot management and API security, businesses can better protect against sophisticated automated threats while gaining visibility to detect and mitigate risks before they cause a security incident.
As API ecosystems continue to expand and bots become more sophisticated, the cost of inaction will only rise. Organizations must address the security risks associated with APIs and bots to protect sensitive data, mitigate financial losses, and safeguard their brand reputation.
Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Twitter and LinkedIn to read more exclusive content we post.
from The Hacker News https://ift.tt/7k2SigP
via IFTTT
Oct 07, 2024The Hacker NewsPassword Security / Data Security
The interest in passwordless authentication has increased due to the rise of hybrid work environments and widespread digitization. This has led to a greater need for reliable data security and user-friendly interfaces. Without these measures, organizations are at risk of experiencing data breaches, leaks, and significant financial losses.
While traditional password-based systems offer protection, they are susceptible to security threats like phishing and identity theft which drives the consideration of going passwordless. Additionally, users often have difficulty remembering multiple passwords, which further jeopardizes security as they tend to reuse the same one for accessing multiple business systems and devices.
However, passwordless methods such as biometrics, smartcards, and multi-factor authentication prioritize both data security and user satisfaction. Nevertheless, not all passwordless authentication systems are the same and exhibit their own challenges.
The need for dependable security measures is largely driven by cyber-attacks and data breaches. In the webinar "Modernization of Authentication: Passwords vs Passwordless and MFA," co-hosts James Azar, CISO, and Darren James, Sr. Product Manager at Specops Software, will offer valuable insights into the evolving landscape of password security and authentication solutions.
Key Take-Aways:
A streamlined and user-friendly approach to securing access and the potential for enhanced security measures.
Potential challenges and security considerations that come with implementing a passwordless strategy.
Why passwords still play a crucial role in certain scenarios organizations.
Understand how MFA serves as a critical layer of security, providing enhanced protection.
The continued relevance of passwords in the context of emerging passwordless technologies.
Save Your Seat:
Increasing cyber threats and evolving compliance standards have created an even greater demand for reliable data protection that preserves unbroken productivity for both in-office and remote teams. The webinar will provide best practices for modern security and authentication, making it valuable for those looking to enhance their current security.
Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Twitter and LinkedIn to read more exclusive content we post.
from The Hacker News https://ift.tt/pkzhol1
via IFTTT
Cybersecurity researchers have discovered a new botnet malware family called Gorilla (aka GorillaBot) that is a variant of the leaked Mirai botnet source code.
Cybersecurity firm NSFOCUS, which identified the activity last month, said the botnet "issued over 300,000 attack commands, with a shocking attack density" between September 4 and September 27, 2024. No less than 20,000 commands designed to mount distributed denial-of-service (DDoS) attacks have been issued from the botnet every day on average.
The botnet is said to have targeted more than 100 countries, attacking universities, government websites, telecoms, banks, gaming, and gambling sectors. China, the U.S., Canada, and Germany have emerged as the most attacked countries.
Besides supporting multiple CPU architectures such as ARM, MIPS, x86_64, and x86, the botnet comes with capabilities to connect with one of the five predefined command-and-control (C2) servers to await DDoS commands.
In an interesting twist, the malware also embeds functions to exploit a security flaw in Apache Hadoop YARN RPC to achieve remote code execution. It's worth noting that the shortcoming has been abused in the wild as far back as 2021, according to Alibaba Cloud and Trend Micro.
Persistence on the host is achieved by creating a service file named custom.service in the "/etc/systemd/system/" directory and configuring it to run automatically every time at system startup.
The service, for its part, is responsible for downloading and executing a shell script ("lol.sh") from a remote server ("pen.gorillafirewall[.]su"). Similar commands are also added to "/etc/inittab," "/etc/profile," and "/boot/bootcmd" files to download and run the shell script upon system startup or user login.
"It introduced various DDoS attack methods and used encryption algorithms commonly employed by the Keksec group to hide key information, while employing multiple techniques to maintain long-term control over IoT devices and cloud hosts, demonstrating a high level of counter-detection awareness as an emerging botnet family," NSFOCUS said.
Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.
from The Hacker News https://ift.tt/SZrW3iP
via IFTTT
Oct 07, 2024Ravie LakshmananCybersecurity / Mobile Security
Google has announced that it's piloting a new security initiative that automatically blocks sideloading of potentially unsafe Android apps in India, after similar tests in Singapore, Thailand, and Brazil.
The enhanced fraud protection feature aims to keep users safe when they attempt to install malicious apps from sources other than the Google Play Store, such as web browsers, messaging apps, and file managers.
The program, which was first launched in Singapore earlier this February, has already blocked nearly 900,000 high-risk installations in the Southeast Asian nation, the tech giant said.
"This enhanced fraud protection will analyze and automatically block the installation of apps that may use sensitive permissions frequently abused for financial fraud," Eugene Liderman, director of mobile security strategy at Google, said.
It works by examining the permissions declared by a third-party app in real-time and checking for permissions that are typically abused by malicious apps to read SMS messages and notifications, and leverage the accessibility services to serve overlays and perform other malicious actions.
Should any of the permissions be declared in the app's manifest ("AndroidManifest.xml") file, Google Play Protect will intervene to automatically block the installation on the end user's Android device.
The pilot is expected to start next month and is expected to be gradually rolled out to all Android devices running Google Play services in the country.
"For developers distributing apps that may be affected by this pilot, now is a good time to review the permissions your app is requesting and ensure you're following developer best practices," Liderman said.
The development comes nearly a year after Google launched DigiKavach (meaning "digital armor") in India to combat online financial fraud and safeguard users against scams and malware.
"Through this program, we're studying the methods and modus operandi of scammers, developing and implementing countermeasures to new emerging scams, and responsibly sharing these insights with committed experts and partners, to collectively help create a safer and more secure digital ecosystem for all," Google India head Sanjay Gupta noted back in October 2023.
Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.
from The Hacker News https://ift.tt/0y8MzCW
via IFTTT
We’ve recently been informed by the Google Play store that our developer account has been terminated and all Kaspersky apps have been removed from the store.
Google’s decision refers to recent U.S. government actions restricting the distribution and sales of Kaspersky products in the United States after September 29. Although these restrictions have no material legal effect outside the U.S., Google unilaterally decided to remove our products from Google Play ahead of September 29 – depriving users worldwide of access to industry-leading cybersecurity protection.
We believe that Google’s decision is based on overinterpretation of the U.S. restrictions, which was not backed by a confirmation from the U.S. Department of Commerce. The U.S. restrictive measures don’t prohibit the sales and distribution of Kaspersky’s products and services outside the United States. We have communicated this understanding to the U.S. Department of Commerce, and we hope to receive additional guidance from the Department shortly.
What will happen to already-installed Kaspersky apps for Android?
Apps that were installed from Google Play will continue to work normally and receive database updates through our cloud infrastructure. All paid app features will also continue to work. Unfortunately, you won’t be able to update or reinstall an app directly from Google Play.
How to install and update Kaspersky apps for Android now?
Europe's top court has ruled that Meta Platforms must restrict the use of personal data harvested from Facebook for serving targeted ads even when users consent to their information being used for advertising purposes, a move that could have serious consequences for ad-driven companies operating in the region.
"An online social network such as Facebook cannot use all of the personal data obtained for the purposes of targeted advertising, without restriction as to time and without distinction as to type of data," the Court of Justice of the European Union (CJEU) said in a ruling on Friday.
In other words, social networks, such as Facebook, cannot keep using users' personal data for ad targeting indefinitely, the court said, adding limits must be set in place in order to comply with the bloc's General Data Protection Regulation (GDPR) data minimization requirements.
It's worth noting that Article 5(1)(c) of GDPR necessitates that companies limit the processing to strictly necessary data, preventing the collected personal data about an individual -- whether gathered on or outside the platform via third-parties -- from being aggregated, analyzed, and processed for targeted advertising without time-bound restrictions.
The case was originally filed by privacy activist and noyb (None Of Your Business) co-founder Maximilian "Max" Schrems in 2014 over claims that the social media giant targeted him with personalized ads based on his sexual orientation.
"The fact that a person has made a statement about his or her sexual orientation on the occasion of a public panel discussion does not authorize the operator of an online social network platform to process other data relating to that person's sexual orientation, obtained, as the case may be, outside that platform using partner third-party websites and apps, with a view to aggregating and analyzing those data, in order to offer that person personalized advertising," the CJEU said.
Noyb, in a statement, said it welcomed the ruling and that the result was along expected lines, stating the judgment also extends to any other online advertisement company that does not have stringent data deletion practices.
"Meta and many players in the online advertisement space have simply ignored this rule and did not foresee any deletion periods or limitations based on the type of personal data," the Austrian non-profit said.
"The application of the 'data minimisation principle' radically restricts the use of personal data for advertising. The principle of data minimisation applies regardless of the legal basis used for the processing, so even a user who consents to personalized advertising cannot have their personal data used indefinitely."
In a statement shared with Reuters, Meta said it has made monetary efforts to "embed privacy" in its products, noting it "does not use special categories of data that users provide to personalize ads while advertisers are not allowed to share sensitive data."
The development comes as Texas Attorney General Ken Paxton has filed a lawsuit against ByteDance-owned TikTok for alleged violations of child privacy laws in the U.S. state, otherwise called the Securing Children Online Through Parental Empowerment (SCOPE) Act.
The lawsuit accused TikTok of failing to provide adequate tools that allow parents and guardians to control the privacy and account settings of children aged between 13 and 17.
"For example, parents or guardians do not have the ability to control [TikTok's] sharing, disclosing, and selling of a known minor's personal identifying information, nor control [TikTok's] ability to display targeted advertising to a known minor," the lawsuit reads.
"Texas law requires social media companies to take steps to protect kids online and requires them to provide parents with tools to do the same," Paxton said. "TikTok and other social media companies cannot ignore their duties under Texas law."
TikTok, which prohibits targeted advertising for anyone under 18, said it strongly disagreed with the allegations and that it offers "robust safeguards for teens and parents, including family pairing, all of which are publicly available."
Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.
from The Hacker News https://ift.tt/r4H2Qb5
via IFTTT
Effective today, we have made some changes to the Snort Sample IP Block List available on Snort.org
The Snort Sample IP Blocklist has been a steady component of our open-source Snort community since its launch. It was originally provided so the community could test the functionality of their Snort installation, and it was never intended to be users’ sole source of IP blocking.
Traditionally, this is list of suggested IPs to block based on other open-source IP block lists. But over the past several years, we have seen an increasing number of users relying on the Snort Sample IP Blocklist as their primary source of IP Blocking, which may lead to a false sense of protection from threats.
To ensure the intention and legal usage of this blocklist is clear to all our users, we will be enabling a “click-to-accept” terms and conditions box for users to access the Snort Sample IP Blocklist hosted on Snort.org. This change will outline the legal terms and conditions for use of the blocklist, which clearly documents the intended use of the data.
We will continuously update the Snort Sample IP Blocklist on Snort.org regularly and provide it free to all users to ensure that Snort is functioning as intended.
You can download the Snort Sample IP Block List here.
Oct 05, 2024Ravie LakshmananData Privacy / Mobile Security
Apple has released iOS and iPadOS updates to address two security issues, one of which could have allowed a user's passwords to be read out aloud by its VoiceOver assistive technology.
The vulnerability, tracked as CVE-2024-44204, has been described as a logic problem in the new Passwords app impacting a slew of iPhones and iPads. Security researcher Bistrit Daha has been credited with discovering and reporting the flaw.
"A user's saved passwords may be read aloud by VoiceOver," Apple said in an advisory released this week, adding it was resolved with improved validation.
The shortcoming impacts the following devices -
iPhone XS and later
iPad Pro 13-inch
iPad Pro 12.9-inch 3rd generation and later
iPad Pro 11-inch 1st generation and later
iPad Air 3rd generation and later
iPad 7th generation and later, and
iPad mini 5th generation and later
Also patched by Apple is a security vulnerability (CVE-2024-44207) specific to the newly launched iPhone 16 models that allows audio to be captured before the microphone indicator is on. It's rooted in the Media Session component.
"Audio messages in Messages may be able to capture a few seconds of audio before the microphone indicator is activated," the iPhone maker noted.
The problem has been fixed with improved checks, it added, crediting Michael Jimenez and an anonymous researcher for reporting it.
Users are advised to update to iOS 18.0.1 and iPadOS 18.0.1 to safeguard their devices against potential risks.
Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.
from The Hacker News https://ift.tt/xMz6Ww0
via IFTTT
This article reviews four previously undisclosed domain name system (DNS) tunneling campaigns that occurred in recent months. We identified these new campaigns through our recently deployed campaign monitoring system, which can identify new, potentially malicious campaigns from daily tunneling detection.
DNS tunneling is a technique threat actors use to encode non-DNS traffic data within DNS packet traffic. This allows the information to bypass traditional network firewalls and establish covert communication channels for data exfiltration and infiltration.
Our new campaign monitoring system is designed to detect tunneling domains based on the techniques and attributes commonly used in malicious campaigns. These unique intercorrelations among individual tunneling campaigns can reveal new tunneling domains.
For example, can attackers connect a new domain to any existing well-documented tunneling campaign? Do a couple of recently detected tunneling domains originate from an undisclosed campaign?
Hence, instead of investigating the tunneling domains individually, we seek to analyze these domains from the perspective of common attributes and quickly uncover new campaigns.
We have deployed this tunneling campaign monitoring system in our Advanced DNS Security service. This system allows organizations to secure their DNS traffic by identifying and blocking new potential campaigns from tunneling domains. It also provides detailed campaign information for customers who can log in to our Test A Site service.
Palo Alto Networks Next-Generation Firewall customers can access the tunneling campaign information with the Advanced DNS Security subscription and receive protections against malicious indicators (domains and IP addresses) mentioned in this article via Advanced URL Filtering. The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the IoCs shared in this research.
The Next-Generation Firewall with the Advanced Threat Prevention security subscription can help block the attacks with best practices by identifying the corresponding malware samples and command and control (C2) traffic.
Palo Alto Networks Cortex Analytics customers receive protection against DNS tunneling techniques mentioned in this article via the DNS tunneling analytics detector.
Cortex also helps protect against malware from the Hiloti family and others through features such as prevention for shellcode injection.
DNS is a critical component of the internet infrastructure responsible for translating human-readable domain names into IP addresses. Many organizations leave UDP and TCP port 53 open in their firewalls, which is the port DNS uses for communication. They also often leave this port unmonitored, making it an attractive target for attackers to use as a covert communications channel.
DNS tunneling leverages the DNS protocol to encode data within DNS queries and responses. Therefore, cyberattackers tend to use DNS tunneling for data exfiltration, command and control (C2), or bypassing security measures.
Figure 1. The hidden information is transmitted via DNS tunneling attacks.
Figure 1 illustrates an example of covert communications using DNS tunneling techniques.
Attackers first infect a client system with malware that is able to steal the user’s data. Then, the stolen data is encoded and embedded within subdomains and is transmitted over DNS queries. The attackers can receive and decode the data by hosting an authoritative DNS (aDNS) server of the root domain (e.g., helloworld[.]com in Figure 1).
DNS tunneling can achieve stealthiness because the recursive DNS servers enable indirect communications between client systems and attacker-controlled authoritative DNS servers. Attackers are also able to transmit commands by encoding data into DNS responses.
Malicious actors also abuse DNS tunneling in attack campaigns. For example, the Iranian threat group Evasive Serpens (aka OilRig) employed DNS tunneling to communicate between infected hosts and their C2 servers, targeting critical infrastructure in the Middle East. Another Iranian threat group we track as Obscure Serpens (aka DarkHydrus) also used DNS tunneling when it targeted government agencies and educational institutions in the Middle East in 2016.
The detection of DNS tunneling has typically focused on the attributes of individual domains, such as lexical or infrastructure patterns. However, defenders often overlook additional attributes.
For example, correlations between tunneling domains can help us monitor significant clusters for tunneling detection and discover emerging campaigns. In this article, we reveal common attributes shared within individual campaigns that could facilitate automated detection of new DNS tunneling campaigns.
Based on these attributes, we have designed and deployed the first campaign monitoring system in our products. This system aims to automatically determine if a couple of historically detected tunneling domains originate from an undisclosed campaign, or if a new tunneling domain belongs to any existing well-documented campaign.
Attributes for Campaign Monitoring
This section presents methods that can identify new tunneling campaigns from daily tunneling detection results. Our detection relies on the fact that domains used in each individual tunneling campaign typically exhibit similar attributes because the same malicious actors registered the domains, or the campaigns used the same tunneling methods.
We discuss the common attributes we identified within each tunneling campaign. To the best of our knowledge, these distinctive intercorrelations among tunneling campaigns have not been fully studied previously.
The following attributes relate to infrastructure, configurations, lexical patterns and targets that could be shared across the tunneling domains in each campaign:
Authoritative nameserver: The nameservers used by tunneling campaigns are usually owned and controlled by attackers themselves, as attackers should have unrestricted access to fetch query logs and manipulate the response. To limit the attack cost, attackers tend to use a single self-hosted authoritative DNS server. This centralized server enables them to efficiently manage and process DNS traffic of multiple tunneling domains.
DNS configurations: In a single tunneling campaign, the DNS configurations used for each domain are usually similar or even identical. This is because the same attacker group sets and stores the configuration in the same aDNS server. The shared infrastructure settings allow attackers to effectively deploy and control the various domains in the campaign, but they also provide a significant indicator for security researchers. For instance, RussianSite and 8NS tunneling campaigns have their own DNS configuration pattern with a single aDNS IP address.
Payload encoding: To launch a tunneling campaign, attackers usually employ consistent tunneling tools or encoding methods to encapsulate their payload data into subdomains. Therefore, within a single campaign, the patterns of subdomains across various root domains often show significant similarities. This consistency helps attackers manage their C2 or data exfiltration processing. For example, RussianSite and NSfinder use the same encoding method within each campaign.
Domain registration: Domains used in individual campaigns frequently share the same top-level domain (TLD). Also, the associated root domains use a notably similar naming scheme, indicating a consistent choice made by the attacker group. Moreover, the registration time of these domains tends to align closely from their WHOIS records.
Attack target: Each tunneling campaign tends to target one or a few specific victim types (e.g., governments, public infrastructures, finance/banking/investments or health/medical care).
Based on the above criteria, we used machine learning techniques to explore the potential new campaigns among the detected tunneling domains.
New Campaigns
By focusing on the correlations between DNS tunneling domains, we detected four previously undiscovered campaigns. Each campaign shares some attributes from infrastructure, payloads, domain registration or targeted victims. We show the detailed case studies on these campaigns in this section.
FinHealthXDS
The first campaign contains 12 domains that use a customized DNS beaconing format for Cobalt Strike C2 communications. While Cobalt Strike has a default configuration for DNS C2 communications through a malleable C2 profile, this campaign leverages a customized format.
In this format, the associated DNS queries use three-letter prefixes (e.g., xds) to indicate the function of the queries used in this tunneling traffic. This campaign targets the finance and healthcare industries, thus we named it FinHealthXDS.
By analyzing the passive DNS records, we discovered this customized Cobalt Strike DNS beaconing format. This campaign uses the xds prefix to indicate command request queries and resolves to 40.112.72[.]205 as the IP address.
After obtaining the returned IP address such as 40.112.72[.]62, malware will calculate the XOR value of the last byte to determine the returned command. For example, 205 XOR 62 = 243, which typically indicates transferring data with TXT records (mode dns-txt command).
Below, we find two examples of DNS A record queries for transferring subsequent data using TXT records.
xds.5af195b6.gear.<rootdom> A 40.112.72[.]205
xds.5af195b6.gear.<rootdom> A 40.112.72[.]62
This campaign can use either A records or TXT records for an infected host to receive data. When using A records, the DNS queries follow a format with a customized prefix of pro (compared to the default value of cdn when using malleable C2 profiles for DNS beaconing in Cobalt Strike).
pro.[hex-counter][8-digit-hex-random-number].[beacon-id].[subdomain-padding].<rootdom> A [hex-infiltration-data]
When using TXT records for data infiltration, the DNS queries use the prefix snd instead of the default api prefix used in the malleable C2 for DNS beaconing in Cobalt Strike. An example of the format is shown below.
To exfiltrate data to a C2 server, the DNS queries leverage two prefixes (i.e., txt for short messages and del for long messages, not the default prefix of post). The format is as follows.
[txt|del].[num-of-message][encoded-message].[counter][random-number].[beacon-id].[subdomain-padding].<rootdom> A 40.112.72[.]205
Table 1 shows six domains in this campaign. It also shows the query samples, nameservers and nameserver IP addresses.
Domain
Query Sample
Nameserver Domains
Nameserver IP Address
pretorya[.]site
h3t5b.g.pretorya[.]site
ns1.g.pretorya[.]site
ns2.g.pretorya[.]site
185.161.248[.]253
zzczloh[.]site
ptqo1.p.zzczloh[.]site
ns1.p.zzczloh[.]site
ns2.p.zzczloh[.]site
185.161.248[.]253
mouvobo[.]site
jpdqo.n.mouvobo[.]site
ns1.n.mouvobo[.]site
ns2.n.mouvobo[.]site
185.161.248[.]253
mponiem[.]site
6nesl.v.mponiem[.]site
ns1.v.mponiem[.]site
ns2.v.mponiem[.]site
185.161.248[.]253
linkwide[.]site
g49wo.y.linkwide[.]site
ns1.y.linkwide[.]site
ns2.y.linkwide[.]site
185.161.248[.]253
dtodcart[.]site
lv1bi.f.dtodcart[.]site
ns1.f.dtodcart[.]site
ns2.f.dtodcart[.]site
185.161.248[.]253
Table 1. The domain, query sample, nameservers and nameserver IP addresses in the campaign FinHealthXDS.
RussianSite
The second tunneling campaign contains over 100 domains, all of which share the same nameserver IP address of 185.161.248[.]253 from Russia. Most domains in this campaign end with the TLD .site, while only a very few of these domains use .website. Therefore, based on the aDNS IP address and the TLD patterns, we named this campaign RussianSite.
The subdomain contains two parts: a 5-character alphanumeric payload and a 1-letter or 2-letter padding that is specific in each domain. The A records of these campaign domains are distributed worldwide. However, to receive tunneling information from aDNS servers, configuring a valid aDNS IP address is mandatory for attackers, while A records are discretionary and could be invalid.
In Table 2 we listed examples of the domains, along with a query sample, nameservers and nameserver IP address. We have obfuscated the listed FQDN queries so no customer data is revealed.
We observed this campaign targeting 10 organizations from higher education. Of these 10 targets, five are governments and public infrastructure, four are medical/health institutions and one is a public accounting firm.
Domain
Query Sample
Nameserver Domains
Nameserver IP Address
pretorya[.]site
h3t5b.g.pretorya[.]site
ns1.g.pretorya[.]site
ns2.g.pretorya[.]site
185.161.248[.]253
zzczloh[.]site
ptqo1.p.zzczloh[.]site
ns1.p.zzczloh[.]site
ns2.p.zzczloh[.]site
185.161.248[.]253
mouvobo[.]site
jpdqo.n.mouvobo[.]site
ns1.n.mouvobo[.]site
ns2.n.mouvobo[.]site
185.161.248[.]253
mponiem[.]site
6nesl.v.mponiem[.]site
ns1.v.mponiem[.]site
ns2.v.mponiem[.]site
185.161.248[.]253
linkwide[.]site
g49wo.y.linkwide[.]site
ns1.y.linkwide[.]site
ns2.y.linkwide[.]site
185.161.248[.]253
dtodcart[.]site
lv1bi.f.dtodcart[.]site
ns1.f.dtodcart[.]site
ns2.f.dtodcart[.]site
185.161.248[.]253
Table 2. The domain, query sample, nameservers, nameserver IP address in the campaign RussianSite.
8NS
The third tunneling campaign contains six domains that share the same DNS configurations and aDNS server IP address of 35.205.61[.]67. A special pattern of this campaign is that each domain has 8 NS records. Therefore, we named this campaign 8NS.
However, instead of keeping redundancy of nameservers, all the NS records (i.e., ns[1-8].<rootdom>) have the same A record of 35.205.61[.]67.
<rootdom>NSns1.<rootdom>
<rootdom>NSns2.<rootdom>
<rootdom>NSns3.<rootdom>
<rootdom>NSns4.<rootdom>
<rootdom>NSns5.<rootdom>
<rootdom>NSns6.<rootdom>
<rootdom>NSns7.<rootdom>
<rootdom>NSns8.<rootdom>
ns[1-8].<rootdom>A35.205.61[.]67
<rootdom>A35.205.61[.]67
Meanwhile, the A record of the root domain is the same as the aDNS server IP address. That indicates the nameserver may be self-built, which is usually a premise for DNS tunneling. Below, Figure 2 shows a visual mapping of the 8NS campaign.
Figure 2. The graph representation of the campaign 8NS.
This campaign is driven by multiple Trojans. For example, malware from the Hiloti family 0b99db286f3708fedf7e2bb8f24df1af13811fe46b017b6c3e7e002852479430, can contact the domain 011807dd0303[.]lantzel[.]com.
This Hiloti sample secretly downloads malicious files from a remote server and then injects the unpacked malware into explore[.]exe. The malware creates three registry entries under HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\Bfetipi or HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Bfetipi, which a C2 domain generation algorithm uses to send client online messages to the C2 server through DNS queries, as depicted in Figure 3.
Figure 3. Code from a Hiloti sample that sends DNS messages to a C2 server.
The generated domains are based on the information of infected systems, with a format such as the following:
Let’s break down the encoding of each component from the above example:
0018786966: Elapsed time
96428380: Infected machine volume serial number XOR 0x3C2C3DB7
04: Number of processor cores on the infected machine
5E43287B03114C04A64F68C0C23E44F4: Generated from the registry key “Jqoqegemidar” and XOR algorithm
n: Indicator of a new process (n) or existing process (e), determined by mutex
156: Value of registry key “Nwasolonizo”
887: Hard-coded value
empty: Hard-coded value
6_1: OS information: OS major version (6) and minor version (1)
_t_i: Hard-coded
3000: Current process security identifier (SID)
explorer_exe: Malware executing process name
156: Hard-coded
rc2[.]a4h9uploading[.]com: Hard-coded domain
After sending a client online message, the malware starts C2 communication with the domain lantzel[.]com, which Figure 4 shows being decrypted during execution.
Figure 4. Disassembled code from a Hiloti sample showing that it decrypts the domain lantzel[.]com during execution.
We illustrate these six domains in the campaign 8NS, along with the query sample, nameservers and nameserver IP address in Table 3.
Table 3. The domain, query sample, nameservers and nameserver IP address in the campaign 8NS.
NSfinder
The fourth campaign contains over 50 domains. All domains are named by combining three words with the last word of finder (e.g., unlimitedpartnersfinder[.]com). The subdomains are composed of multiple similar segments, each of which contains a prefix ns500 and a number. Based on the root domain and subdomain patterns, we named this campaign NSfinder.
NSfinder is related to multiple malicious IP addresses, mainly from Europe. Each domain typically uses three IP addresses each time for both aDNS IP addresses and resolved IP addresses.
The IP addresses used by different domains have high overlapping. Also, we observe that attackers periodically change the IP address set for each domain, and the time to live (TTL) is only 60 seconds.
NSfinder performs attacks by setting up adult websites, and it lures victims to enter their credit card information. This campaign also correlates with multiple Trojans, such as IcedID.
For example, attackers frequently used the nameserver IP address 206.188.197[.]111 in the campaign to communicate with a malware sample with the SHA256 hash dfb3e5f557a17c8cdebdb5b371cf38c5a7ab491b2aeaad6b4e76459a05b44f28, identified as IcedID by different sources in VirusTotal. The nameserver IP address 185.81.114[.]183 communicated with the malware c22d25107e48962b162c935a712240c0a4486b38891855f0e53d5eb972406782, identified as RedLine stealer.
We observed this campaign having massive traffic within one month in 2023. The ns500 tokens have over a hundred variants, where the top tokens follow the distribution of English letters. We observed thousands of victims related to this campaign, mainly coming from high tech, education and manufacturing fields.
In Table 4, we list six domain examples with their query sample, nameservers and nameserver IP addresses.
Table 4. The domain, query sample, nameservers and nameserver IP addresses in the campaign NSfinder.
Conclusion
The domains within each tunneling campaign share some common attributes, such as the following:
Infrastructure
DNS configurations
Payload encoding
Domain registration patterns
Attack targets
These attributes enable us to identify significant clusters among the tunneling detection results so that we can discover the emerging tunneling campaigns.
This method of detection has revealed four new campaigns that we have described in this article and have named:
FinHealthXDS
RussianSite
8NS
NSfinder
We have implemented these techniques as a new campaign monitoring system into our Advanced DNS Security service, providing campaign information and descriptions to our customers. With this system, we have detected four new campaigns from daily tunneling detection results.
Customers can also receive protections against malicious indicators (domains, IP addresses) mentioned in this article via Advanced URL Filtering.
The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the IoCs shared in this research.
Palo Alto Networks Cortex Analytics customers receive protection against DNS tunneling techniques mentioned in this article via the DNS tunneling analytics detector.
Cortex also helps protect against malware from the Hiloti family and others through features such as prevention for shellcode injection.
If you think you might have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America Toll-Free: 866.486.4842 (866.4.UNIT42)
EMEA: +31.20.299.3130
APAC: +65.6983.8730
Japan: +81.50.1790.0200
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Google launches GARA program to fund and support groundbreaking research in computing and technology, addressing global challenges.
