2020 to reach vulnerability disclosure levels similar to those in 2019

The number of vulnerability disclosures is back on track to reach or bypass 2019 as we head into 2021, according to Risk Based Security. The team aggregated 17,129 vulnerabilities disclosed during the first three quarters of 2020, marking a 4.6% gap when compared to last year. However, earlier in 2020 that gap was instead a sharp decline of 19.2%. “At the end of Q1 this year, we saw what appeared to be a sharp decline … More

The post 2020 to reach vulnerability disclosure levels similar to those in 2019 appeared first on Help Net Security.

D-Link routers vulnerable to remotely exploitable root command injection flaw

The Digital Defense Vulnerability Research Team uncovered a previously undisclosed vulnerability affecting D-Link VPN routers. D-Link DSR-150, DSR-250, DSR-500 and DSR-1000AC VPN routers running firmware version 3.14 and 3.17 are vulnerable to a remotely exploitable root command injection flaw.

D-Link routers vulnerability

These devices are commonly available on consumer websites/ecommerce sites such as Amazon, Best Buy, Office Depot and Walmart. Given the rise in work-from-home due to the pandemic, more employees may be connecting to corporate networks using one of the affected devices.

Accessible without authentication

The vulnerable component of these devices is accessible without authentication. From both WAN and LAN interfaces, this vulnerability could be exploited over the internet. Consequently, a remote, unauthenticated attacker with access to the router’s web interface could execute arbitrary commands as root, effectively gaining complete control of the router.

With this access, an attacker could intercept and/or modify traffic, cause denial of service conditions and launch further attacks on other assets. D-Link routers can connect up to 15 other devices simultaneously.

Updates are available

“Our standard practice is to work in tandem with organizations on a coordinated disclosure effort to facilitate a prompt resolution to a vulnerability. The Digital Defense VRT reached out to D-Link who worked diligently on a patch.

“We will continue outreach to customers ensuring they are aware and able to take action to mitigate any potential risk introduced by the vulnerability,” states Mike Cotton, senior vice president of engineering at Digital Defense.

D-Link’s advisory provides more details about the updates that have been released, which should be applied.

Open source vulnerabilities go undetected for over four years

For its annual State of the Octoverse report, GitHub has analyzed over 45,000 active code directories to provide insight into open source security (vulnerabilities) and developers’ practices regarding vulnerability reporting, alerting and remediation.

The Microsoft subsidiary found that security vulnerabilities often go undetected for more than four years before being disclosed.

Open source vulnerabilities

Additional findings

Security vulnerabilities can impact software directly or through its dependencies.

After examining a year-worth of data collected through its dependency graph, the company has found that most projects on GitHub have at least one open source dependency.

The percentage is highest for those using JavaScript (94%), Ruby (90%), and .NET (90%). JavaScript and Rudy projects also have the highest number of median direct dependencies (10 and 9, respectively), and JavaScript has by far the highest number of median transitive dependencies (i.e., their direct dependencies have additional dependencies themselves).

Another interesting finding is that most open source software vulnerabilities are caused by mistakes, not malicious attacks.

“Analysis on a random sample of 521 advisories from across our six ecosystems finds that 17% of the advisories are related to explicitly malicious behavior such as backdoor attempts. Of those 17%, the vast majority come from the npm ecosystem,” they shared.

The most blatant indicator of a backdoor is an attacker gaining commit access to a package’s source code repository, usually via an account hijack, they explained, and the last line of defense against these attempts is careful peer review in the development pipeline, especially of changes from new committers.

“Many mature projects have this careful peer review in place. Attackers are aware of that, so they often attempt to subvert the software outside of version control at its distributition points or by tricking people into grabbing malicious versions of the code through, for example, typosquatting a package name.”

Not that vulnerabilitities introduced by mistake cannot be just as disruptitive as malicious attack – they can, and they are much more likely to impact popular projects, GitHub noted.

Add to this the discovery that a vulnerability typically goes undetected for over four years, and you can see how problems may arise.

Best practices to improve the situation

“Security is always a concern when working with software. Our analysis shows that potential vulnerabilities found scale with the number of lines of code written,” they noted.

“The power and promise of open source is in the power of the community. By joining forces with millions of developers to not only build software packages but also identify and fix vulnerabilities, we can build software more quickly and more securely.”

The key, they say, is to leverage automated alerting and patching tools. “Our own analysis found that repositories that automatically generated a pull request to update to the fixed version patched their software in 33 days, which is 13 days faster than those who did not, or 1.4 times faster.”

The effectiveness of vulnerability disclosure and exploit development

New research into what happens after a new software vulnerability is discovered provides an unprecedented window into the outcomes and effectiveness of responsible vulnerability disclosure and exploit development.

effectiveness vulnerability disclosure

The analysis of 473 publicly exploited vulnerabilities challenges long-held assumptions of the security space – namely, disclosure of exploits before a patch is available does not create a sense of urgency among companies to fix the problem.

The research was conducted by Kenna Security and the Cyentia Institute. It examines how the common practices among security researchers impact the overall security of corporate IT networks.

The importance of timing

The analysis found that when exploit code is made public prior to the release of a patch, cybercriminals get a critical head start. At the same time, when exploits are released before patches, it takes security teams more time to address the problem, even after the patch is released.

“The debate over responsible disclosure has existed for decades, but this data provides an objective correlation between vulnerability discovery, disclosure, and patch delivery for the first time ever,” said Ed Bellis, CTO of Kenna Security.

“However, the results raise several questions about responsible exposure, demonstrating that the timing of exploit code release can shift the balance in favor of attackers or defenders.”

Whether exploit code is released first or a patch is released first, the research found that there are periods of time when attackers have the momentum and when defenders have momentum – a reflection of the fact that no matter when a patch is released, some companies simply don’t or can’t install it before attackers make their move.

For approximately nine of the 15 months studied in this analysis, attackers were able to exploit vulnerabilities at a higher rate than defenders were patching, while defenders had the upper hand for six months.

The vulnerability disclosure practice

At the heart of the vulnerability disclosure practice is a mix of competing incentives for software publishers, IT teams, and the independent security researchers that find software vulnerabilities.

When a vulnerability is found, researchers disclose its existence and the relevant code they used to exploit the application. The publisher sets about creating a patch and pushing the patch to its user base. Occasionally, however, software publishers don’t engage, declining to create a patch or notify users of a vulnerability.

In these cases, researchers will publicly disclose the vulnerability to warn the larger community and spur the publisher to take action. Google, for example, tells software publishers that it will release details of the vulnerabilities it discovers within 90 days of notification, except in a few scenarios.

Additional findings

  • When exploit code is publicly released before a patch, attackers get, on average, a 47 day head start
  • Only 6% of those exploits were detected by more than 1/100 organizations
  • Exploit code was already available for over 50% of the vulnerabilities in our sample by the time they were published to the CVE List
  • In great news for defenders, over 80% of exploited vulnerabilities have a patch available prior to, or along with, CVE publication
  • About one-third of vulnerabilities have exploit code published before a patch is made available
  • About 7% of vulnerabilities are exploited before a CVE is published, a patch is available, and exploit code is released

“For decision-makers and researchers across the cybersecurity community, this research provides a vital, never before seen window into the lifecycle of vulnerabilities and exploitations,” said Jay Jacobs, partner, Cyentia Institute.

“These findings offer prominent paths for future research that could ultimately make the IT infrastructure more secure.”

Despite the strong relationship between disclosure of exploitation code and weaponization, the research requires some caveats. It’s possible that release of exploit code doesn’t facilitate exploitation, but detection of exploits in the wild, because the release of the code enabled faster creation of anti-virus signatures.

“This new report reignites the conversation on responsible disclosure. More research will help draw more definitive conclusions, but for now, we can say that where there’s smoke, there’s fire,” said Wade Baker, partner and co-founder of Cyentia Institute. “Release of exploit code before a patch seems to have a negative effect on corporate security.”

Google discloses actively exploited Windows zero-day (CVE-2020-17087)

Google researchers have made public a Windows kernel zero day vulnerability (CVE-2020-17087) that is being exploited in the wild in tandem with a Google Chrome flaw (CVE-2020-15999) that has been patched on October 20.

CVE-2020-17087

About CVE-2020-17087

CVE-2020-17087 is a vulnerability in the Windows Kernel Cryptography Driver, and “constitutes a locally accessible attack surface that can be exploited for privilege escalation (such as sandbox escape).”

More technical information has been provided in the Chromium issue tracker entry, which was kept unaccessible to the wider public for the first seven days, but has now been made public.

The researchers have also included PoC exploit code, which has been tested on Windows 10 1903 (64-bit), but they noted that the affected driver (cng.sys) “looks to have been present since at least Windows 7,” meaning that all the other supported Windows versions are probably vulnerable.

Exploitation and patching

Shane Huntley, Director of Google’s Threat Analysis Group (TAG) confirmed that the vulnerability chain is being used for targeted exploitation and that the attacks are “not related to any US election-related targeting.”

The attackers are using the Chrome bug to gain access to the target system and then the CVE-2020-17087 to gain administrator access on it.

A patch for the issue is expected to be released on November 10, as part of the monthly Patch Tuesday effort by Microsoft.

Currently we expect a patch for this issue to be available on November 10.

While the bug is serious, the fact that it’s being used in targeted (and not widespread) attacks should reassure most users they’ll be safe until the patch is released.

Also, according to a Microsoft spokesperson, exploitation of the flaw has only been spotted in conjuction with the Chrome vulnerability, which has been patched in Chrome and other Chromium-based browsers (e.g., Opera on October 21, Microsoft Edge on October 22.

Users who have implemented those updates are, therefore, safer still.

Vulnerability reporting is returning to normal

Vulnerability reporting, still impacted by COVID-19, is beginning to return to normal, Risk Based Security reveals.

vulnerability reporting normal

Out of 11,121 vulnerabilities aggregated during the first half of 2020, 818 were the result of the Vulnerability Fujiwhara Effect, a term that describes the events when Microsoft and Oracle vulnerability disclosure schedules collide.

“Risk Based Security sounded the alarm back in January. We knew that these events would undoubtedly become a significant strain for IT staff and Vulnerability Managers,” commented Brian Martin, Vice President of Vulnerability Intelligence at Risk Based Security.

“Compared to other Patch Tuesdays this year, the highest reported ‘only’ 273 new vulnerabilities. However, during April’s Fujiwhara event we saw 506 new vulnerabilities reported, 79% of which came from seven vendors.

“Unfortunately for all of us, this is likely we can expect to occur more frequently in the future. The sheer volume makes one wonder who actually benefits from this all-at-once disclosure of vulnerabilities. Certainly not the paying customers.”

Vendors and products with the highest vulnerability counts

The report goes further into the details of the disclosure landscape by listing and breaking down the vendors and products with the highest vulnerability counts. Most notable is Microsoft, which has seen a 150% increase in the amount of vulnerabilities disclosed during the first six months of 2020 compared to the entirety of 2019. Windows 10 was the product with the most disclosed vulnerabilities by the end of Q2.

A growing concern is that, despite the high number of Microsoft vulnerabilities and the Vulnerability Fujiwhara, 29.3% of all vulnerabilities disclosed during the first half of 2020 do not have CVE ID, with 3.3% being in RESERVED status meaning that information for those vulnerabilities is not available within the CVE/NVD database.

vulnerability reporting normal

“Given the sheer amount of vulnerabilities disclosed, organizations relying on CVE/NVD will struggle to find timely and actionable intelligence,” Mr. Martin concluded.

“The bare minimum metadata found within NVD is not enough for organizations to properly prioritize and remediate. Organizations are increasing their own risk by relying on CVE to provide complete and timely data. The current level of vulnerability disclosures organizations face on a daily basis are more than CVE can handle, and it will only get worse.”

Most ICS vulnerabilities disclosed this year can be exploited remotely

More than 70% of ICS vulnerabilities disclosed in the first half of 2020 can be exploited remotely, highlighting the importance of protecting internet-facing ICS devices and remote access connections, according to Claroty.

ICS vulnerabilities exploited remotely

The report comprises The Claroty Research Team’s assessment of 365 ICS vulnerabilities published by the National Vulnerability Database (NVD) and 139 ICS advisories issued by the Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) during 1H 2020, affecting 53 vendors. The research team discovered 26 of the vulnerabilities included in this data set.

Compared to 1H 2019, ICS vulnerabilities published by the NVD increased by 10.3% from 331, while ICS-CERT advisories increased by 32.4% from 105. More than 75% of vulnerabilities were assigned high or critical Common Vulnerability Scoring System (CVSS) scores.

“There is a heightened awareness of the risks posed by ICS vulnerabilities and a sharpened focus among researchers and vendors to identify and remediate these vulnerabilities as effectively and efficiently as possible,” said Amir Preminger, VP of Research at Claroty.

“We recognized the critical need to understand, evaluate, and report on the comprehensive ICS risk and vulnerability landscape to benefit the entire OT security community.

“Our findings show how important it is for organizations to protect remote access connections and internet-facing ICS devices, and to protect against phishing, spam, and ransomware, in order to minimize and mitigate the potential impacts of these threats.”

Prominence of RCE vulns highlights need to protect internet-facing ICS devices

According to the report, more than 70% of the vulnerabilities published by the NVD can be exploited remotely, reinforcing the fact that fully air-gapped ICS networks that are isolated from cyber threats have become vastly uncommon.

Additionally, the most common potential impact was remote code execution (RCE), possible with 49% of vulnerabilities – reflecting its prominence as the leading area of focus within the OT security research community – followed by the ability to read application data (41%), cause denial of service (DoS) (39%), and bypass protection mechanisms (37%).

The prominence of remote exploitation has been exacerbated by the rapid global shift to a remote workforce and the increased reliance on remote access to ICS networks in response to the COVID-19 pandemic.

ICS vulnerabilities exploited remotely

Vulnerabilities on the rise

The energy, critical manufacturing, and water & wastewater infrastructure sectors were by far the most impacted by vulnerabilities published in ICS-CERT advisories during 1H 2020.

Of the 385 unique Common Vulnerabilities and Exposures (CVEs) included in the advisories, energy had 236, critical manufacturing had 197, and water & wastewater had 171. Compared to 1H 2019, water & wastewater experienced the largest increase of CVEs (122.1%), while critical manufacturing increased by 87.3% and energy by 58.9%.

Assessment of ICS vulnerabilities discovered

The research team discovered 26 ICS vulnerabilities disclosed during 1H 2020, prioritizing critical or high-risk vulnerabilities that could affect the availability, reliability, and safety of industrial operations.

The team focused on ICS vendors and products with vast install bases, integral roles in industrial operations, and those that utilize protocols in which researchers have considerable expertise. These 26 vulnerabilities could have serious impacts on affected OT networks, because more than 60% enable some form of RCE.

2019 was a record year for OSS vulnerabilities

Total vulnerabilities in OSS more than doubled in 2019 from 421 Common Vulnerabilities and Exposures (CVEs) in 2018 to 968 last year, according to the RiskSense report.

OSS vulnerabilities

Top 10 weaponized CWEs

The study also revealed that it takes a very long time for OSS vulnerabilities to be added to the National Vulnerability Database (NVD), averaging 54 days between public disclosure and inclusion in the NVD. This delay can cause organizations to remain exposed to serious application security risks for almost two months.

These very long lags were seen across all severities including vulnerabilities rated as ‘Critical’ and those that were weaponized, meaning those where an exploit is present in the wild.

“While open source code is often considered more secure than commercial software since it undergoes crowdsourced reviews to find problems, this study illustrates that OSS vulnerabilities are on the rise and may be a blindspot for many organizations,” said Srinivas Mukkamala, CEO of RiskSense.

“Since open source is used and reused everywhere today, when vulnerabilities are found, they can have incredibly far-reaching consequences.”

OSS vulnerabilities doubled in 2019

The number of published open source CVEs more than doubled compared to any previous year. Vulnerabilities increased 130% between 2018 and 2019 (from 421 to 968 CVEs), and was 127% higher than 2017 (435). This increase does not appear to be a flash in the pan since the number of new CVEs has remained at historically high levels through the first three months of 2020.

NVD disclosure latency is dangerously long

Vulnerabilities in open source software are taking an extremely long time to be added to the U.S. NVD. The average time between the first public disclosure of a vulnerability and its addition to the NVD was 54 days.

The longest observed lag was 1,817 days for a critical PostgreSQL vulnerability. 119 CVEs had lags of more than 1 year, and almost a quarter (24%) had lags of more than a month. These lags were consistent across all severities of vulnerabilities, with critical severity vulnerabilities having some of the longest average lag times.

Jenkins & MySQL have the most vulnerabilities

The Jenkins automation server had the most CVEs overall with 646 and was closely followed by MySQL with 624. These two OSS projects also tied for the most weaponized vulnerabilities (those for which exploit code exists) with 15 each.

By contrast, HashiCorp’s Vagrant only had 9 total CVEs, but 6 of them were weaponized, making it one of the most weaponized open source projects in terms of percentage. Meanwhile, Apache Tomcat, Magento, Kubernetes, Elasticsearch, and JBoss all had vulnerabilities that were trending or popular in real-world attacks.

XSS and Input Validation

Cross-Site Scripting (XSS) and Input Validation weaknesses were both some of the most common and most weaponized types of weaknesses in the study. XSS issues were the second most common type of weakness, but were the most weaponized.

Likewise Input Validation issues were the third most common and second most weaponized. Input Validation and Access Control issues were both common and were seen trending in real-world attacks.

OSS vulnerabilities

Projects by percent of weaponized CVEs

Rare does not equal less dangerous

Some weaknesses were far less common, yet remained very popular in active attack campaigns. Deserialization Issue (28 CVEs), Code Injection (16 CVEs), Error Handling Issues (2 CVEs), and Container Errors (1 CVE) were all seen trending in the wild.

The fact that these issues are rare in OSS is a positive sign for the security of open source code, but also serves as a reminder that when problems do arise they can be attacked quite broadly.

Providing real-world context

Open source software now represents a significant percentage of the average organization’s attack surface. And while open source has many benefits, managing vulnerabilities can pose unique challenges.

Despite lower number of vulnerability disclosures, security teams have their work cut out for them

The number of vulnerabilities disclosed in Q1 2020 has decreased by 19.8% compared to Q1 2019, making this likely the only true dip observed within the last 10 years, Risk Based Security reveals.

vulnerabilities disclosed Q1 2020

Vulnerabilities of interest disclosed in Q1 2020

Vulnerabilities disclosed in Q1 2020: What happened?

Many factors have been identified as potential contributors to this decline, including the COVID-19 pandemic, though its precise impact may not be known for another year.

“Although the pandemic has already brought unprecedented changes to all walks of life, it is difficult to predict precisely how it will impact vulnerability disclosures this year,” commented Brian Martin, Vice President of Vulnerability Intelligence at Risk Based Security.

“It is possible, as we’ve seen with data breaches, that some researchers and companies may be slower to disclose vulnerabilities. Between drastic changes in work environments and a global pandemic, vulnerability disclosure totals may be directly impacted.”

Many vulnerabilities lacking detail in CVE

Despite the lower total number of vulnerability disclosures in Q1, security teams have their work cut out for them. 561 vulnerabilities have been identified that have a public exploit, yet do not have any detail in CVE.

Worse, 60.2% of those vulnerabilities are remotely exploitable. This is problematic for many organizations that rely on security tools that are based on CVE data and have little in the way of detection and mitigation.

vulnerabilities disclosed Q1 2020

Top ten products by vulnerability disclosures in Q1 2020, as compared to 2019

“Those vulnerabilities include issues such as remote authentication bypass, stored XSS, SQL injection, information disclosure, denial of service, and more,” Mr. Martin concluded.

“Some of these vulnerabilities are present in software from Symantec, Apple, Atlassian, ManageEngine, Nextcloud, Jetbrains, and IBM to name a few. That should give pause to anyone who has to come up with a mitigation strategy where patching ‘in the right order’ becomes a key strategy.”

FIRST releases updated coordination principles for Multi-Party Vulnerability Coordination and Disclosure

The Forum of Incident Response and Security Teams (FIRST) has released an updated set of coordination principles – Guidelines for Multi-Party Vulnerability Coordination and Disclosure version 1.1.

FIRST coordination principles

Stakeholder roles and communication paths

The purpose

The purpose of the Guidelines is to improve coordination and communication across different stakeholders during a vulnerability disclosure and provide best practices, policy and processes for reporting any issues across multiple vendors.

It is targeted at vulnerabilities that have the potential to affect a wide range of vendors and technologies at the same time.

Previous best practices, policy and process for vulnerability disclosure focused on bi-lateral coordination and did not adequately address the current complexities of multi-party vulnerability coordination.

Factors such as a vibrant open source development community, the proliferation of bug bounty programs, third party software, supply chain vulnerabilities, and the support challenges facing CSIRTs and PSIRTs are just a few of the complicating aspects.

Art Manion, Vulnerability Analysis Technical Manager, CERT Coordination Center said: “As software development becomes more complex and connected to supply chains, coordinated vulnerability disclosure practices need to evolve. The updated Guidelines are a step in that evolution, deriving guidance and principles from practical use cases.”

The content

The Guidelines for Multi-Party Vulnerability Coordination and Disclosure contains a collection of best current practices that consider more complex as well as typical real-life scenarios that go beyond a single researcher reporting a vulnerability to a single company.

The Guidance includes:

  • Establish a strong foundation of processes and relationships
  • Maintain clear and consistent communications
  • Build and maintain trust
  • Minimize exposure for stakeholders
  • Respond quickly to early disclosure
  • Use coordinators when appropriate
  • Multi-Party Disclosure Use Cases

FIRST Chair, Serge Droz said: “The Guidelines for Multi-Party Vulnerability Coordination and Disclosure is an important step towards a better and more responsible way of managing vulnerabilities.

“It was crucial that these Guidelines were created in tandem with key stakeholders who may be affected by multi-party vulnerabilities. I am proud that FIRST was able to bring these stakeholders together to work on this very important document.”

Wormable Windows SMBv3 RCE flaw leaked, but not patched

Yesterday, when Microsoft released its regular Patch Tuesday fixes, Cisco Talos and Fortinet inadvertently(?) also published information about CVE-2020-0796, a “wormable” vulnerability in the Microsoft Server Message Block (SMB) protocol that has yet to be fixed.

CVE-2020-0796

Cisco Talos has since removed the entry but, a few hours later, Microsoft published an advisory offering more information and workarounds to be implemented until a fix is made available.

About CVE-2020-0796

CVE-2020-0796 is a remote code execution vulnerability in the way that the Microsoft Server Message Block 3.1.1 (SMBv3) protocol handles certain requests.

“An attacker who successfully exploited the vulnerability could gain the ability to execute code on the target SMB Server or SMB Client,” Microsof explained.

“To exploit the vulnerability against an SMB Server, an unauthenticated attacker could send a specially crafted packet to a targeted SMBv3 Server. To exploit the vulnerability against an SMB Client, an unauthenticated attacker would need to configure a malicious SMBv3 Server and convince a user to connect to it.”

The vulnerability is not being actively exploited and was discovered internally by Microsoft.

Unlike the Microsoft Windows SMB Server flaws used by the EternalBlue and EternalRomance exploits, which were leveraged for the 2017 WannaCry and NotPetya outbreaks, CVE-2020-0796 only affects SMBv3 and, therefore, does not affect Windows 7 and Windows Server 2008 R2 systems.

According to Microsoft’s advisory, it affects Windows 10 (versions 1903 and 1909) and Windows Server (1903 and 1909).

What to do?

Microsoft advised admins to:

  • Disable SMBv3 compression to block unauthenticated attackers from exploiting the vulnerability against an SMBv3 Server
  • Block TCP port 445 at the enterprise perimeter firewall (since it is used to initiate a connection with the affected component). This action will not stop attacks from within their enterprise perimeter.

There is currently no workaround for mitigating the danger for SMB clients.

I’d say that Microsoft will be rushing to deliver a patch soon to head off attackers who are likely already trying to unearth the flaw.

For the moment, there are no PoC exploits or full exploits available online.

Major vulnerabilities found in popular wireless presentation system

F-Secure consultants have discovered several exploitable vulnerabilities in Barco’s ClickShare wireless presentation system. Attackers can use the flaws to intercept and manipulate information during presentations, steal passwords and other confidential information, and install backdoors and other malware.

wireless presentation system

Popular attack targets

Dmitry Janushkevich, a senior consultant that specializes in hardware security, says the popularity of these user-friendly tools make them logical targets for attack, which is what compelled his team to investigate.

“The system is so practical and easy to use, people can’t see any reason to mistrust it. But its deceptive simplicity hides extremely complex inner workings, and this complexity makes security challenging,” explains Janushkevich. “The everyday objects that people trust without a second thought make the best targets for attackers, and because these systems are so popular with companies, we decided to poke at it and see what we could learn.”

Exploitable flaws in the wireless presentation system

Janushkevich and his F-Secure Consulting colleagues researched the ClickShare system on an on-and-off basis for several months after noticing its popularity during red team assessments. They discovered multiple exploitable flaws, 10 of which have CVE identifiers.

The different issues facilitate a variety of attacks, including intercepting information shared through the system, using the system to install backdoors or other malware on users’ computers, and stealing information and passwords.

While exploiting some of the vulnerabilities requires physical access, others can be done remotely if the system uses its default settings. Furthermore, Janushkevich says the execution of the exploits can be done quickly by a skilled attacker with physical access (possibly while posing as a cleaner or office worker), allowing them to inconspicuously compromise the device.

“Our tests’ primary objectives were to backdoor the system so we could compromise presenters, and steal information as it’s presented. Although cracking the perimeter was tough, we were able to find multiple issues after we gained access, and exploiting them was easy once we knew more about the system,” explains Janushkevich. “For an attacker, this is a fast, practical way to compromise a company, and organizations need to inform themselves about the associated risks.”

Vulnerability disclosure

The researchers shared their findings with Barco on October 9, 2019, and the two companies worked together in a coordinated disclosure effort. Barco published a firmware release on their website to mitigate the most critical vulnerabilities. However, several of the issues involve hardware components that require physical maintenance to address, and are unlikely to get fixed.

“This case highlights how hard it is to secure ‘smart devices’. Bugs in silicon, in the design, and in the embedded software can have long-lasting negative effects on both the vendor and users, undermining the trust we put in these devices,” says Janushkevich.

GitHub Security Lab aims to make open source software more secure

GitHub, the world’s largest open source code repository and leading software development platform, has launched GitHub Security Lab. “Our team will lead by example, dedicating full-time resources to finding and reporting vulnerabilities in critical open source projects,” said Jamie Cool, VP of Product Management, Security at GitHub. GitHub Security Lab GitHub Security Lab is a program aimed at researchers, maintainers, and companies that want to contribute to the overall security of open source software. Current … More

The post GitHub Security Lab aims to make open source software more secure appeared first on Help Net Security.