Tag: Vulnerability

Categories
Links Writing

AI-Assisted Vulnerability Hunting is Here

Aisle’s recent blog, “What AI Security Research Looks Like When It Works,” does a nice job in explaining the utility of LLM-enabled security research. Properly scoped and resourced, researchers can identify serious vulnerabilities that make communities much safer after patches are applied.

However, there is a distinction between high-quality reports and slop-quality reports. Some groups, such as those operating open source projects, are seeing increasing amounts of low-quality reports that are overwhelming their ability to triage incoming reports.

Aisle highlights several emergent challenges associated with LLM-enabled security research:

  1. If vulnerability reporting increases while maintainer numbers remain flat, there is a question of whether this will cause burnout among maintainers and thus impair both security- and feature-related development.
  2. Whether the 90-day responsible disclosure window remains appropriate, or needs to be tightened, in the current era of LLM-assisted discovery. At the same time, how can or should vulnerability reports be deduplicated?
  3. Whether the ability to identify and patch vulnerabilities will ultimately favour defenders or attackers.
  4. The community’s response to a substantial shift in vulnerability discovery remains uncertain.

There are a few other considerations not taken up in Aisle’s blog:

  1. To what extent will the increased ability of attackers to find vulnerabilities shift who is identified as an ‘advanced’ threat actor? While persistence is currently still linked to resourcing to maintain operations, if serious vulnerabilities (and their chains) become more widely discoverable, what effect will this have on a broader subset of actors being able to conduct cyber operations?
  2. In what ways will the organizations producing foundational models need to build in user identity or verification functionalities or access controls to potentially restrict who can (and cannot) use the models to undertake cybersecurity research?
  3. What might occur if adversaries attempt to poison training data or model weights in order to impede specific forms of LLM-enabled cybersecurity research, either now or in the future?
Categories
Writing

Details from the DNI’s Annual VEP Report

For a long time external observers wondered how many vulnerabilities were retained vs disclosed by FVEY SIGINT agencies. Following years of policy advocacy there is some small visibility into this by way of Section 6270 of Public Law 116-92. This law requires the U.S. Director of National Intelligence (DNI) to disclose certain annual data about the vulnerabilities disclosed and retained by US government agencies.

The Fiscal Year 2023 VEP Annual Report Unclassified Appendix reveals “the aggregate number of vulnerabilities disclosed to vendors or the public pursuant to the [VEP] was 39. Of those disclosed, 29 of them were initial submissions, and 10 of them were reconsiderations that originated in prior years.”1

There can be many reasons to reassess vulnerability equities. Some include:

  1. Utility of given vulnerabilities decrease either due to changes in the environment or research showing a vulnerability would not (or would no longer) have desired effect(s) or possess desired operational characteristics.
  2. Adversaries have identified the vulnerabilities themselves, or through 4th party collection, and disclosure is a defensive action to protect US or allied assets.
  3. Independent researchers / organizations are pursuing lines of research that would likely result in finding the vulnerabilities.
  4. By disclosing the vulnerabilities the U.S. agencies hope or expect adversaries to develop similar attacks on still-vulnerable systems, with the effect of masking future U.S. actions on similarly vulnerable systems.
  5. Organizations responsible for the affected software (e.g., open source projects) are now perceived as competent / resourced to remediate vulnerabilities.
  6. The effects of vulnerabilities are identified as having greater possible effects than initially perceived which rebalances disclosure equities.
  7. Orders from the President in securing certain systems result in a rebalancing of equities regarding holding the vulnerabilities in question.
  8. Newly discovered vulnerabilities are seen as more effective in mission tasks, thus deprecating the need for the vulnerabilities which were previously retained.
  9. Disclosure of vulnerabilities may enable adversaries to better target one another and thus enable new (deniable) 4th party collection opportunities.
  10. Vulnerabilities were in fact long used by adversaries (and not the U.S. / FVEY) and this disclosure burns some of their infrastructure or operational capacity.
  11. Vulnerabilities are associated with long-terminated programs and the release has no effect of current, recent, or deprecated activities.

This is just a very small subset of possible reasons to disclose previously-withheld vulnerabilities. While we don’t have a strong sense of how many vulnerabilities are retained each year, we do at least have a sense that rebalancing of equities year-over-year(s) is occurring. Though without a sense of scale the disclosed information is of middling value, at best.

  1. A locally stored version of the document is also available. ↩︎
Categories
Writing

Computers-on-Wheels and Web-Based Vulnerabilities

While there can be significant efficiencies gained by increasing the amount of data that is accessible by motor vehicles, connecting these computers-on-wheels to the Internet can have notable consequences.

Recent reporting by Wired reveals, as an example, that:

… a group of independent security researchers revealed that they’d found a flaw in a web portal operated by the carmaker Kia that let the researchers reassign control of the internet-connected features of most modern Kia vehicles—dozens of models representing millions of cars on the road—from the smartphone of a car’s owner to the hackers’ own phone or computer. By exploiting that vulnerability and building their own custom app to send commands to target cars, they were able to scan virtually any internet-connected Kia vehicle’s license plate and within seconds gain the ability to track that car’s location, unlock the car, honk its horn, or start its ignition at will.

…

“If someone cut you off in traffic, you could scan their license plate and then know where they were whenever you wanted and break into their car,” says Curry. “If we hadn’t brought this to Kia’s attention, anybody who could query someone’s license plate could essentially stalk them.” For Kias that come installed with a 360-degree camera, that camera, too, was accessible to hackers. Beyond allowing the hijacking of connected features in cars themselves, Curry says, the web portal flaw also allowed hackers to query a broad range of personal information about Kia customers—names, email addresses, phone numbers, home addresses, and even past driving routes in some cases—a potentially massive data leak.

The nature of the vulnerability is particularly concerning:

When the researchers sent commands directly to the API of that website—the interface that allows users to interact with its underlying data—they say they found that there was nothing preventing them from accessing the privileges of a Kia dealer, such as assigning or reassigning control of the vehicles’ features to any customer account they created.

I do have to admit that I appreciate that this started with discovering issues with APIs used by scooters, which led the researchers to become “super interested in trying more ways to make more things honk.”

Categories
Links Writing

Mandatory Patching of Serious Vulnerabilities in Government Systems

Photo by Mati Mango on Pexels.com

The Cybersecurity and Infrastructure Security Agency (CISA) is responsible for building national capacity to defend American infrastructure and cybersecurity assets. In the past year they have been tasked with receiving information about American government agencies’ progress (or lack thereof) in implementing elements of Executive Order 14028: Improving the Nation’s Cybersecurity and have been involved in responses to a number of events, including Solar Winds, the Colonial Pipeline ransomware attack, and others. The Executive Order required that CISA first collect a large volume of information from government agencies and vendors alike to assess the threats towards government infrastructure and, subsequently, to provide guidance concerning cloud services, track the adoption of multi factor authentication and seek ways of facilitating its implementation, establish a framework to respond to security incidents, enhance CISA’s threat hunting abilities in government networks, and more.1

Today, CISA promulgated a binding operational directive that will require American government agencies to adopt more aggressive patch tempos for vulnerabilities. In addition to requiring agencies to develop formal policies for remediating vulnerabilities it establishes a requirement that vulnerabilities with a common vulnerabilities and exposure ID be remediated within 6 months, and all others with two weeks. Vulnerabilities to be patched/remediated are found in CISA’s “Known Exploited Vulnerabilities Catalogue.”

It’s notable that while patching is obviously preferred, the CISA directive doesn’t mandate patching but that ‘remediation’ take place.2 As such, organizations may be authorized to deploy defensive measures that will prevent the vulnerability from being exploited but not actually patch the underlying vulnerability, so as to avoid a patch having unintended consequences for either the application in question or for other applications/services that currently rely on either outdated or bespoke programming interfaces.

In the Canadian context, there aren’t equivalent levels of requirements that can be placed on Canadian federal departments. While Shared Services Canada can strongly encourage departments to patch, and the Treasury Board Secretariat has published a “Patch Management Guidance” document, and Canada’s Canadian Centre for Cyber Security has a suggested patch deployment schedule,3 final decisions are still made by individual departments by their respective deputy minister under the Financial Administration Act.

The Biden administration is moving quickly to accelerate its ability to identify and remediate vulnerabilities while simultaneously lettings its threat intelligence staff track adversaries in American networks. That last element is less of an issue in the Canadian context but the first two remain pressing and serious challenges.

While its positive to see the Americans moving quickly to improve their security positions I can only hope that the Canadian federal, and provincial, governments similarly clear long-standing logjams that delegate security decisions to parties who may be ill-suited to make optimal decisions, either out of ignorance or because patching systems is seen as secondary to fulfilling a given department’s primary service mandate.

  1. For a discussion of the Executive Order, see: “Initial Thoughts on Biden’s Executive Order on Improving the Nation’s Cybersecurity” or “Everything You Need to Know About the New Executive Order on Cybersecurity.” ↩︎
  2. For more, see CISA’s “Vulnerability Remediation Requirements“. ↩︎
  3. “CCCS’s deployment schedule only suggests timelines for deployment. In actuality, an organization should take into consideration risk tolerance and exposure to a given vulnerability and associated attack vector(s) as part of a risk‑based approach to patching, while also fully considering their individual threat profile. Patch management tools continue to improve the efficiency of the process and enable organizations to hasten the deployment schedule.” Source: “Patch Management Guidance” ↩︎
Categories
Quotations

2019.1.14

Between 2002 and 2009, the [Industrial Control System Cyber Emergency Response Team] conducted more than 100 site assessments across multiple industries–oil and natural gas, chemical, and water–and found more than 38,000 vulnerabilities. These included critical systems that were accessible over the internet, default vendor passwords that operators had never bothered to change or hard-coded passwords that couldn’t be changed, outdated software patches, and a lack of standard protections such as firewalls and intrusion-detection systems.

But despite the best efforts of the test-bed and site-assessment researchers, they were battling decades of industry intertia–vendors took months and years to patch vulnerabilities that government researchers found in their systems, and owners of crucial infrastructure were only willing to make cosmetic changes to their systems and networks, resisting more extensive ones.

Kim Zetter, Countdown to Zero-Day
Categories
Links Writing

19 Year-Old Vulnerability Continues to Haunt the Internet

Via Ars Technical:

A surprisingly big number of top-name websites—Facebook and PayPal among them—recently tested positive for a critical, 19-year-old vulnerability that allowed attackers to decrypt encrypted data and sign communications using the sites’ secret encryption key.

The vulnerability in the transport layer security protocol for Web encryption was disclosed in 1998 when researcher Daniel Bleichenbacher found it in the TLS predecessor known as secure sockets layer. A flaw in the algorithm that handles RSA encryption keys responded to certain types of errors in a way that divulged potentially sensitive information. With enough specially formed queries, attackers could exploit the weakness in a way that allowed them to decrypt ciphertext even when they didn’t have the secret decryption key. SSL architects responded by designing workarounds that suppressed the error messages rather than removing or rewriting the faulty RSA algorithm.

…

The vulnerability of Cisco’s ACE is concerning, because Cisco stopped supporting it several years ago and the researchers said the company has no plans to patch the product line. Even worse, it’s not possible to disable RSA encryption in the product, leaving users unable to follow one of the few possible workarounds for those unable to patch. What’s more, the researchers said Cisco is currently using ACE to serve content on cisco.com.

Companies that are responsible for providing critical infrastructure technologies need to be accountable for what they develop and sell. Imagine if a car company with a known-deficient vehicle refused to fix or repair it on the basis they didn’t support it any longer – there’d be class action suits almost immediately. The technology sector need to mature, and fast.

But as an aside, these are the sorts of weaknesses and vulnerabilities that the NSA and other national security agencies, along with private signals intelligence vendors, actively exploit. The actual ways in which cryptography is implemented are often rife with issues. One has to ask why Cisco and other major companies’ products were vulnerable in the first place but, also, whether the NSA or its sister agencies knew about the weaknesses and have been exploiting them instead of trying to better secure the public’s communications.

In theory the United States of America’s government, as well as the Canadian government, has a Vulnerabilities Equities Process (VEP). If this vulnerability was discovered but not disclosed it would be a damning indictment of the adequacy of the current VEP protocols.

Categories
Links

US-CERT: Stop using your remotely exploitable Netgear routers

From Network World:

In case you are wondering, that firmware for the R7000 – Nighthawk AC1900 smart router – is the newest firmware available by Netgear. Here are Netgear’s links to the R8000 – Nighthawk AC3200 tri-band gigabit router and the R6400. Hopefully those – and any other vulnerable models – will soon be updated with less insecure firmware.

Hopefully less insecure firmware will be provided to turn a burning dumpster fire into a merely-smouldering-mess. Hurray for (possible, but don’t bet on it) progress.

Categories
Links

1 million Google accounts compromised by Android malware called Gooligan

From Ars Technica:

Researchers say they’ve uncovered a family of Android-based malware that has compromised more than 1 million Google accounts, hundreds of them associated with enterprise users.

Gooligan, as researchers from security firm Check Point Software Technologies have dubbed the malware, has been found in at least 86 apps available in third-party marketplaces. Once installed, it uses a process known as rooting to gain highly privileged system access to devices running version 4 (Ice Cream Sandwich, Jelly Bean, and KitKat) and version 5 (Lollipop) of Google’s Android operating system. Together, the vulnerable versions account for about 74 percent of users.

…

Update: In a separate blog post also published Wednesday morning, Android security engineer Adrian Ludwig said he and other Google officials have worked closely with Check Point over the past few weeks to investigate Gooligan and to protect users against the threat it poses. He said there’s no evidence data was accessed from compromised accounts or that individual users were targeted. He also said Google has been using a service called Verify Apps to scan individual handsets for signs of Gooligan and other Ghost Push apps. When detected, device owners receive a warning and installations are halted.

“We’ve taken many actions to protect our users and improve the security of the Android ecosystem overall,” Ludwig wrote. “These include: revoking affected users’ Google Account tokens, providing them with clear instructions to sign back in securely, removing apps related to this issue from affected devices, deploying enduring Verify Apps improvements to protect users from these apps in the future and collaborating with ISPs to eliminate this malware altogether.”

While Google is taking this threat seriously – which is a good thing! – there is the problem where handsets shipping without the Google Play Store will remain vulnerable to this and other kinds of malware, unless those other app stores also try to warn users. Even Google’s warning system is, really, some chewing gum to cover up a broader security issue: a huge majority of Android phones have an outdated version of Android installed and will likely never see operating system or security updates. These vulnerabilities will continue, unabated, until Google actually can force updates to its partners. And history says that’s not likely to happen anytime soon.

Categories
Links

Two critical bugs and more malicious apps make for a bad week for Android

Ars Technica:

It was a bad week for millions of Android phone users. Two critical vulnerabilities were disclosed but remain unpatched in a large percentage of devices, while, separately, malicious apps were downloaded as many as 2.5 million times from Google’s official Play Marketplace.

The vulnerabilities, which are similar in severity to the Stagefright family of bugs disclosed last year, have been fixed in updates Google began distributing Tuesday. A large percentage of Android phones, however, aren’t eligible to receive the fixes. Even those that do qualify don’t receive them immediately (the September updates are currently not available as over-the-air downloads for either of the Nexus 5X devices in my household). That gives attackers crude blueprints for exploiting vulnerabilities that remain unpatched on millions of devices.

The bag of hurt continues unabated.

Categories
Links Writing

Google rebuilt a core part of Android to kill the Stagefright vulnerability for good

Google rebuilt a core part of Android to kill the Stagefright vulnerability for good:

Android’s security team patched the initial bug within weeks, but it inspired a wave of new attacks on the way Android processes audio and video files. The first copycat bugs were reported just days after the first patch, with more serious exploits arriving months later. The most recent Android patch report, released today, patches three separate vulnerabilities in Android’s media-processing function, including one critical flaw that could be used for remote code execution.

Now, Android is rebuilding that system from the ground up. When Android 7.0 Nougat began rolling out to phones last month, it came with a rebuilt media playback system, specifically designed to protect against the Stagefright family of attacks. In a post today, Android’s security team revealed new details on exactly how Nougat security has changed and what the team learned from last year’s string of bugs.

The vulnerability is more fully and truly patched! Hurray!

A shame that few users will ever receive an update to the new version of Android, let alone the patches in the previous (version 6) of Android. The best/easiest way for most users to ‘update’ an Android-based mobile phone is to throw their current phone in the trash and buy a new one…and even then, the phone they buy will likely lack recent patches. Heck, they’ll be lucky if it has the most recent operating system!

This stands directly in contrast to iOS. Apple can push out a global patch and there are remarkably high levels of uptake by end-users. Google’s method of working with handset manufacturers and carriers alike puts end-users are greater and greater risk. They’re simply making available dangerous products. They’re behaving worse than Microsoft in the Windows XP days!