A vulnerability in Batik of Apache XML Graphics allows an attacker to run Java code from untrusted SVG via JavaScript. This issue affects Apache XML Graphics prior to 1.16. Users are recommended to upgrade to version 1.16.

**Email display mode:**

Modern rendering  
Legacy rendering

CVE-2022-42890

A vulnerability in Batik of Apache XML Graphics allows an attacker to run untrusted Java code from an SVG. This issue affects Apache XML Graphics prior to 1.16. It is recommended to update to version 1.16.

CVE-2022-41704

Apache Geode versions up to 1.15.0 are vulnerable to a Cross-Site Scripting (XSS) via data injection when using Pulse web application to view Region entries.

CVE-2022-34870

Usermin through 1.850 allows a remote authenticated user to execute OS commands via command injection in a filename for the GPG module.

CVE-2022-35132: Webmin

Cybersecurity pros discuss a trio of lessons from the Equifax hack and how to prevent similar attacks in the enterprise.

On the morning of Sept. 7, 2017, US credit bureau giant Equifax announced hackers had infiltrated its network and exfiltrated customer names, Social Security numbers, birthdates, and addresses. The news of the breach — which compromised the private records of 147.9 million Americans (almost 50% of the entire US population), 15.2 million Britons, and almost 19,000 Canadians — immediately created pandemonium across organizations, forcing many business leaders to reconsider their security postures. Much has changed over the past five years, but the lessons from the Equifax breach are still relevant for enterprises.

Equifax didn't reveal the breach as soon as it discovered it — the company sat on the information for more than a month. It was the perfect antithesis: A business known to provide credit score rating, fraud solutions, financial marketing, and analytical services had been hacked. The attackers had gotten in through an unpatched vulnerability in Apache Struts. The worst part? Apache had already warned about the flaw and a patch was available.

"The Equifax breach is a unique attack in that a conscious decision was made by a company and its leadership: not to patch the vulnerability when the software vendor announced the vulnerability and provided the patch," says James Turgal, vice president of cyber risk, strategy, and board relations at Optiv.

The attack, now linked to four hackers from the Chinese military, represents one of the most sweeping attacks conducted against US businesses by foreign nationals. Industry experts discuss with Dark Reading what lessons to draw from the breach and how organizations can prevent similar threats in their environments.

**Data Management Is Still an Enterprise Problem**

"Equifax shows that organizations need to focus on data management," Adam Marrè, CISO at Arctic Wolf and former FBI special agent/cyber investigator, tells Dark Reading.

"With so many different IT and security priorities, companies aren't thinking about data management in the right ways. Most organizations only think about how best to monetize data or how to use it to serve their customers, but they often miss the significant increase in risk that storing the data brings."

Turgal agrees, noting that enterprises and individuals are at risk of data exfiltration and identity theft.

"Every day, companies large and small fall victim to identity theft," he says. "Both the high volume of activity and large transactions occurring at the corporate level attract threat actors, using data that typically has been exfiltrated from another breach by a separate threat actor and sold to the highest bidder to impersonate the identity of a business to commit fraud."

Gartner estimates that until 2025, "80% of organizations seeking to scale digital business will fail because they do not take a modern approach to data governance." That's a lot of businesses, and it's a figure that Marrè agrees with.

"In my experience, most companies don't have a comprehensive picture of how they collect, store, and manage data," he says. "Especially from a security standpoint, most businesses have no idea who has access to what data, how to properly classify it, how to protect it, and even how to set up data retention policies to properly get rid of it. By focusing on these aspects, businesses can transform their data strategies and further protect themselves and their customers."

Turgal suggests that organizations can safeguard data and identity by doing the following:

*   Include artificial intelligence and machine-learning technologies into the business processes to quickly spot anomalous behavior.
*   Review and update access permissions and utilize data encryption when the data is in transit and at rest.
*   Establish protocols for user provisioning and deprovisioning of regular and privileged access holders.
*   Continually educate employees on how to minimize risk.

**Enterprises Aren't Paying Attention to the Basics**

The fundamentals of cybersecurity are still lacking in several enterprise efforts at securing user data. Leaning on his experience in the FBI and private sector, Marrè says he has seen so many organizations that are not adequately prioritizing security. With security incidents at high-profile businesses and rampant ransomware and extortion attacks worldwide, organizations can no longer afford to ignore or sideline their security, he says.

"Although there are new and exciting technologies that are aimed at solving different attack vectors, focusing on successfully executing the fundamentals of cybersecurity remains the most effective strategy," Marrè says. "When it comes to protecting your organization and your data, prevention is good, but detection is a must."

Many attacks can be avoided by implementing zero-trust architecture to the letter. In hindsight, for example, the Equifax attack could have been prevented if the organization had paid more attention to the multiple threat warnings the company had received before the hack.

The Equifax breach was "a strong example of why enterprises should evaluate their data to understand the business need and ensure it is classified appropriately," says Andrew Bayers, head of threat intelligence at Resilience, adding that data should be stored and transmitted securely — and ultimately retained for only the amount of time needed.

**Cyber Resilience Needs Action, Not Reaction**

While it's true that some players in the enterprise are investing heavily in cybersecurity, several others are still lagging — giving malicious actors an opening to capitalize on discrepancies and take control of critical data assets. Although its activities are not immediately noticeable, a proactive cybersecurity team is worth its weight in gold.

"Having a skilled security team is the backbone of a sound cybersecurity strategy," Marrè says. "Whether it's a world-class team from a partner or in-house experts, this should be a priority for all companies."

To become cyber resilient, Bayers adds, organizations should identify vulnerabilities in their systems and prioritize patching according to the risks they pose.

Equifax's Lessons Are Still Relevant, 5 Years Later

Introduction
In many ways, the software supply chain is similar to that of manufactured goods, which we all know has been largely impacted by a global pandemic and shortages of raw materials. 
However, in the IT world, it is not shortages or pandemics that have been the main obstacles to overcome in recent years, but rather attacks aimed at using them to harm hundreds or even thousands of

**Introduction**

In many ways, the software supply chain is similar to that of manufactured goods, which we all know has been largely impacted by a global pandemic and shortages of raw materials.

However, in the IT world, it is not shortages or pandemics that have been the main obstacles to overcome in recent years, but rather attacks aimed at using them to harm hundreds or even thousands of victims simultaneously. If you've heard of a cyber attack between 2020 and today, it's likely that the software supply chain played a role.

When we talk about an attack on the software supply chain, we are actually referring to two successive attacks: one that targets a supplier, and one that targets one or more downstream users in the chain, using the first as a vehicle.

In this article, we will dive into the mechanisms and risks of the software supply chain by looking at a typical vulnerability of the modern development cycle: the presence of personal identifying information, or "secrets", in the digital assets of companies. We will also see how companies are adapting to this new situation by taking advantage of continuous improvement cycles.

**The supply chain, at the heart of the IT development cycle****What is the supply chain?**

Today, it is extremely rare to see companies producing software 100% in-house. Whether it's open source libraries, developer tools, on-premise or cloud-based deployment and delivery systems, or _software-as-a-service_ (SaaS) services, these building blocks have become essential in the modern software factory.

Each of these "bricks" is itself the product of a long supply chain, making the software supply chain a concept that encompasses every facet of IT: from hardware, to source code written by developers, to third-party tools and platforms, but also data storage and all the infrastructures put in place to develop, test and distribute the software.

The supply chain is a layered structure that allows companies to implement highly flexible software factories, which are the engine of their digital transformation.

The mass reuse of open-source components and libraries has dramatically accelerated the development cycle and the ability to deliver functionality according to customer expectations. But the counterpart to this impressive gain has been a loss of control over the origin of the code that goes into the companies' products. This chain of dependencies exposes organizations and their customers to vulnerabilities introduced by changes outside their direct control.

This is obviously a major cybersecurity issue, and one that is only increasing as the supply chain becomes more and more complex year over year. So it's no surprise that large-scale cyber attacks have been able to exploit it to their advantage recently.

**The risk of the weak link**

For hackers, the software supply chain of companies represents an interesting target for several reasons. First of all, because of its complexity and the number of interacting "bricks" at the heart of the software factory, its attack surface is very large. Secondly, application security, which was historically focused on securing the application in production (i.e. exposed to the public), often lacks the visibility and tools to effectively secure internal _build_ servers and other parts of the CI/CD pipeline.

In addition, it's important to understand that the development chain today is continuously evolving, adding new tools constantly. This is one of the defining characteristics of the DevOps movement, which has blurred the line between development and operations enormously, leaving developers free to deliver features for their customers as quickly as possible.

These choices though are often implemented without oversight and can be very different from one team to another, even within the same department. The accumulation of slightly different tools, libraries and platforms makes it very difficult to create accurate inventories which are the cornerstone of effective security management.

Finally, by exploiting the supply chain, hackers find ways to maximize the impact, and therefore the yield, of an attack. To understand this, we must consider that the products and services of a software services company's supply chain are the building blocks of other supply chains. An attacker who has successfully infiltrated one link in a chain can compromise the entire user base, which can have disastrous consequences.

**The rise of supply chain attacks**

In the SolarWinds attack, between March and June 2020, approximately 18,000 Orion platform customers, including a number of U.S. government agencies, downloaded updates with malicious code injected into them. This code granted unauthorized backdoor access to systems and private networks. SolarWinds did not discover the breach until December 2020. An international scandal ensued.

A few weeks later, in January 2021, an attacker obtained credentials used in Docker image creation involving Codecov software, due to an error in the build process. These credentials allowed the attacker to hijack Codecov, a software for testing developers' code coverage, and turn it into a real Trojan horse: since the software is used in continuous integration (CI) environments, it has access to the secret credentials of the build processes (we'll come back to this).

The attacker was thus able to siphon off hundreds of credentials from Codecov users, allowing him to access as many secure systems. The company only detected the breach a few months later, in April.

On July 2, 2021, some ninety days later, a sophisticated ransomware group exploited a vulnerability in Kaseya Virtual System Administrator (VSA) servers - affecting approximately 1,500 small businesses. Kaseya is a developer of network, system and infrastructure management software used by managed service providers (MSPs) and other IT contractors. Although a ransomware attack took control of the customers' systems, the attack was contained and defeated after a few days.

But this is not the biggest supply chain vulnerability of 2021. In December 2021, a few months after the Kaseya incident, what is arguably the simplest but most widespread attack on the software supply chain occurred. After an initial proof-of-concept (POC) was disclosed, attackers began a massive exploitation of a vulnerability affecting Apache Log4j, an extremely popular open-source logging library in the Java ecosystem.

Although an update fixing the problem was proposed relatively quickly, the fact that this library, maintained by only a handful of people, is used on a very large scale around the world, and rarely in a transparent way, has created a huge attack surface that will take years to resolve: the U.S. Cybersecurity and Infrastructure Security Agency (CISA) has just described it as "endemic," meaning that it will probably resurface within the next decade.

Despite its magnitude, this vulnerability is far from being an isolated case: the number of attacks using the open source ecosystem as a propagation vector to reach supply chains has increased by 650% between 2020 and 2021. The European Cybersecurity Agency (ENISA) predicts that supply chain attacks will increase fourfold by 2022.

All of these attacks and vulnerabilities have highlighted the lack of visibility and tools to effectively protect the supply chain, whether it be systems to inventory the use of open-source components, to verify their integrity, or to prevent the leakage of sensitive information. On this last point, it is important to take a step back and look more closely at this key element of security.

**The key to the supply chain: secrets**

Getting hold of unencrypted credentials is the perfect way for a hacker to pivot and move down the supply chain from a supplier to its customers: with valid credentials, attackers operate as authorized users, and post-intrusion detection becomes much more difficult.

From a defensive standpoint, hard-coded secrets are a unique type of vulnerability. Source code is a very leaky asset because it is by nature intended to be frequently cloned and distributed on multiple machines. In fact, the secrets in the source code travel with it. But even more problematic is that code also has a 'memory'.

Today any code repository is managed through a version control system (VCS), usually Git, which keeps a perfect timeline of all the changes that have been made to the files in the code base, sometimes over decades. The problem is that still-valid secrets can hide anywhere on that timeline, opening up a new dimension, this time historical, to the software attack surface.

Unfortunately, most security scans are limited to checking the current, deployed or soon-to-be-deployed state of an application's source code. In other words, when it comes to secrets buried in an old commit or even a never-deployed branch, traditional tools are completely blind.

Last year alone, more than 6 million secrets were published in public repos on GitHUb alone: on average, 3 commits out of every 1,000 contained a secret This is a fifty percent increase from the previous year.

A large number of these secrets gave access to corporate resources. It is important to understand that even if the majority of open source projects hosted on GitHub are personal repositories, it is very easy for a professional developer to inadvertently publish code giving access to corporate resources. It happens regularly!

It is therefore not surprising that a malicious actor looking to carry out an attack on the software supply chain would take a close look at the public repositories on GitHub: they would have a good chance of discovering flaws at hand, primarily secrets present in the source code that would allow him to authenticate himself to a system without arousing any suspicion.

Once a secret is published, it must immediately be considered as compromised: a simple experiment consists in voluntarily publishing a "canary token", i.e. a code having quite the appearance of a valid secret, with an alert mechanism triggered when it is used. The time between the publication and the alert is 4 seconds on average! This space is closely monitored and actively exploited.

To neutralize the risk of intrusion as quickly as possible, there is only one solution: the immediate revocation of the secret. But, by panic or lack of technical knowledge, some people try to cover the error by adding a commit that erases the secret, which does not mitigate the security flaw at all: indeed, Git keeps track of all the code history added, modified or deleted over time. In practice, this means that it is difficult to erase all traces of a past error. It also means that, in many cases, the secret will remain available online even after it has been removed from the "final" state of the code.

But the problems do not end there. In our scenario, as the file containing the secret is replaced by a "clean" file, the secret will no longer be detectable either during manual code review by a peer (a common practice), or by traditional application security tools such as scanners, which also only consider the most recent version of the source code. Worse, the flaw will be duplicated every time the code is cloned, and therefore risks being propagated silently for a long time. In other words, a godsend for hackers.

On July 3, the CEO of crypto-currency giant Binance warned of a massive breach that allegedly leaked "1 billion records of \[Chinese\] residents" belonging to the Shanghai police, including "name, address, national identity, cell phone, police and medical records." The cause? A fragment of source code containing the secret to connecting to a titanic database of personal information was allegedly copied and pasted onto a blog by developers of the Chinese CSDN.

**Private repos also affected**

Unsurprisingly, this is only the tip of the iceberg. Private repositories hide many more secrets than their public counterparts. Working in a closed environment provides a false sense of security, making contributors a little less suspicious, and therefore statistically more likely to "let a secret leak". Tolerating the presence of secrets in non-publicly exposed repositories would be a big mistake.

Indeed, no matter how private these repositories are, the secrets they contain could be used as leverage in an attack, allowing adversaries who had access to the repository to pivot to other systems or elevate their privileges. There are many hacking scenarios, but they all have one thing in common: using any found secrets to maximize the impact of an attack.

Application security teams are well aware of the problem. Unfortunately, the amount of work involved in investigating, revoking and rotating secrets every week is simply overwhelming, let alone digging through years of unexplored code.

Cybersecurity teams are taking hard-coded secrets in source code, and the risks they bring, very seriously. They are ranked 15th among the most "common and impactful" vulnerabilities in the famous CWE Top 25 list 2022 (Common Weakness Enumeration).

A key difference, often forgotten that separates this vulnerability from all others, as the previous examples have shown us is that secrets found in the source code are exploitable without the software being in production! In other words, it is the code itself that carries a vulnerability, not the underlying logic.

We have therefore seen how secrets represent a critical element in securing the supply chain. Let's now look at how organizations are responding to this new threat in the development cycle.

**The response of organizations: bring security into the development cycle****The emergence of DevSecOps**

Software supply chains have many grey areas that are not addressed by traditional security methods. Organizations have realized the need to introduce security into the development lifecycle that strikes the right balance between productivity and resilience.

This is how the DevSecOps movement was born. DevSecOps consists of inserting security into DevOps practices. As a reminder, DevOps is a development philosophy that brings together processes and technologies that allow developers to cooperate more effectively with operational teams. We often talk about the DevOps pipeline (the backbone of the software supply chain) which is characterized by its continuity: it is about being able to integrate, test, validate and deliver code in pre-production, in a continuous way.

Traditional security approaches were _at_ odds with the DevOps philosophy: deliver faster and faster and adapt as you go. There was significant friction between the application security teams and the developer teams, with very different cultures, expertise and methods. This divide, a source of many misunderstandings, _ultimately_ contributed to the fragility of the development cycle.

For security managers, the challenge was to maintain the velocity of DevOps while reinforcing improved security posture: including security rules from the earliest stages of the development cycle (planning, design), disseminating best practices, and reducing the mean time to remediation (MTTR) by capturing more "benign" flaws earlier.

More than a method, it is above all an ideal towards which companies wish to strive. The path is not a long one: cultural differences are tenacious and often take years to fade away. Several avenues have been put forward to promote this transition.

The first avenue is to rely on modern tools. Developers adopt intuitive tools that integrate perfectly with their work environments: the command line, API, IDE (Integrated Development Environment), or even their version control system (VCS). Until recently, the typical security analyst's tools were far removed from this world, with very specific and often impenetrable jargon. Security software vendors have made great strides in this area, offering developers the opportunity to become familiar with security concepts and become self-sufficient over a wide area.

Automation is also key for enabling the creation of effective security systems. Software engineers are specialists in automation, so it really made no sense that they could not implement, or even understand, the security rules imposed on them in order to protect the supply chain. They are also the most knowledgeable about the systems that need to be defended. Combining their knowledge with the expertise of security engineers allows for the best use of available resources and overall happier teams.

Perhaps the most important element of DevDecOps is the idea that security must be part of **all** the stages of the development cycle. Its security can not just exist as a simple checklist to be ticked off just before the launch of a new version.

To achieve this result, it is essential to address an important concept: shared responsibility.

**Shared responsibility and shift-left**

The new security model means sharing responsibility among all members involved in the project. Sharing within cross-functional teams, rather than in silos, which was historically the case (a single independent team in charge of security, audit, and quality assurance).

The term "shift left" is often used to illustrate this desire to move security out of its silo in order to move security operations earlier and save money on detection and remediation. However, this term, popularized in the early 2000s, describes a desired operational outcome rather than a real way to achieve it. For an organization wishing to embark on a DevSecOps transformation, it is better to focus on how to induce this change in order to effectively secure its software supply chain.

The empowerment of developers is an essential driver for this. As the first artisans of the digital world, they must be involved in security decisions in order to take their needs and working methods into account. A simple but powerful guideline is to always make the shortest path also the safest.

Thus, a tool for preventing the most common errors (such as forgetting secrets in the source code) should be easy to use and not create friction with the way teams develop code. A good tool must prove its usefulness and value without feeling like it will result in 'vendor lock.' It should also be able to interface with the security teams, which are not going to disappear! On the contrary security teams, which tend to be smaller than their corresponding dev teams must be mobilized quickly for the most complex cases.

In the past, application security was considered an area that had to remain impenetrable to ensure its effectiveness, but those days are gone. Today, there is a desire for security testing to be done throughout the cycle and for the results to allow remediation without necessarily escalating to the security teams.

Promoting ownership of security at each stage of the cycle requires a general effort of transparency between all teams. This is a mandatory condition for creating an environment of trust and fostering a culture that refuses to use blame as an accountability tool.

In fact, even functions that are further away from the technical domain must be part of this transformation. For example, product managers must also take into account the safety of the products they design in their decision-making process.

The response of companies to face the new risks of the software supply chain will therefore be technical as well as organizational. Collaboration between the different professions working along the supply chain is now a priority for information systems security.

_**Note —** This article is written and contributed by Thomas Segura, technical content writer at GitGuardian._

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

How the Software Supply Chain Security is Threatened by Hackers

Heron versions <= 0.20.4-incubating allows CRLF log injection because of the lack of escaping in the log statements. Please update to version 0.20.5-incubating which addresses this issue.

**Package**

maven org.apache.heron:heron-api (Maven)

**Affected versions**

< 0.20.5-incubating

**Patched versions**

0.20.5-incubating

GHSA-95w5-q9vp-5vrm: Heron allows CRLF log injection

Mishandling of untrusted input issue resolved by developers

John Leyden 24 October 2022 at 14:46 UTC

Mishandling of untrusted input issue resolved by developers

Security researchers have discovered a serious vulnerability in HyperSQL DataBase (HSQLDB) that poses a remote code execution (RCE) risk.

HSQLDB offers a Java\-based SQL relational database system. The technology – which is the second most popular embedded SQL database with 100 million downloads to date – is used for development, testing, and deployment of database applications.

HSQLDB is used by more than 3,120 Maven packages including LibreOffice, JBoss, Log4j, Hibernate, and Spring-Boot as well as various enterprise software packages.

**Parsing problem**

Security researchers from Code Intelligence discovered the RCE vulnerability (tracked as CVE-2022-41853 and rated with a near-maximum CVSS severity score of 9.8) after running a series of fuzzing tests.

More precisely, they found that the parsing procedure for binary and text format data in the java.sql.Statement and java.sql.PreparedStatement components of the technology were flawed.

All versions of the software up to and including HSQLDB version 2.7.0 are vulnerable. Code Intelligence contacted HSQL Development Group, the developers of HSQLDB, who responded promptly by putting together a fix and a workaround that helps safeguard previous versions.

Catch up on the latest secure development news and analysis

HSQLDB is yet to respond to a request for comment from The Daily Swig but security researchers from Code Intelligence have confirmed that a patch is in the pipeline.

“The issue is already fixed upstream and will be available in the next release,” Code Intelligence said. “From version 2.7.1. the property hsqldb.method\_class\_names must be defined with a list of class names or wild cards if any Java static method is used as an HSQLDB routine target.”

The previous implementations caused a problem because the use of Java static methods, except those in java.lang.Math, should not be allowed without defining the system property or else problems can arise.

**Root cause**

A technical write-up of the issue by Code Intelligence explains the root cause of the problem in more depth.

“By default, SQL statements can be used to call any static method from any Java class in the class path. HSQLDB (HyperSQL DataBase) allowed direct use of methods,” a post on Medium last week explains.

The vulnerability means that using java.sql.Statement or java.sql.PreparedStatement in pre-patch versions of HSQLDB along with untrusted input may leave applications vulnerable to an RCE attack.

In response to queries from The Daily Swig, Khaled Yakdan, co-founder of Code Intelligence, explained that an app does not have to be vulnerable to SQL injection for the issue to come into play.

“The current default configuration allows static methods of any class that is on the classpath to be used,” Yakdan said. “Moreover, direct use of methods is allowed for legacy compatibility.”

Yakden declined to speculate on which particular apps might be vulnerable, but he was able to explain the impact of the flaw in cases where it was activated.

“We only focus on finding bugs and don’t investigate which code bases are vulnerable,” Yakden told The Daily Swig. “The impact of this CVE is that if you use HyperSQL to process queries that include (untrusted) user input, attackers may be able to cause your app to execute arbitrary code.”

RELATED Apache Commons Text RCE: Resemblance to Log4Shell but exposure risk is ‘much lower’

HyperSQL DataBase flaw leaves library vulnerable to RCE

Cross-site scripting vulnerability in BookStack versions prior to v22.09 allows a remote authenticated attacker to inject an arbitrary script.

Since BookStack can hold important information for users you should be aware of any potential security concerns. Read through the below to ensure you have secured your BookStack instance. Note, The below only relates to BookStack itself. The security of the server BookStack is hosted on is not instructed below but should be taken into account.

If you’d like to be notified of new potential security concerns you can sign-up to the BookStack security mailing list. For reporting security vulnerabilities, please see the “Security” section of the project readme on GitHub.

*   Initial Security Setup
*   Multi-Factor Authentication
*   Securing Images
*   Attachments
*   User Passwords
*   JavaScript in Page Content
*   Web Crawler Control
*   Secure Cookies
*   Host Iframe Control
*   Iframe Source Control
*   Failed Access Logging
*   Untrusted Server Side Requests
*   Content Security Policy (CSP)
*   MySQL SSL Connection
*   Using BookStack Content Externally

**Initial Security Setup**

1.  Ensure you change the password and email address for the initial admin@admin.com user.
2.  Ensure only the public folder is being served by your webserver. Serving files above this folder opens up a lot of code that does not need to be public. Triple check this if you have installed BookStack within the commonly used /var/www folder.
3.  Ensure the database user you’ve used for BookStack has limited permissions for only accessing the database used for BookStack data.
4.  Check that you’ve set the APP_URL option in your .env file so that system generated URLs cannot be manipulated.
5.  Within BookStack, go through the settings to ensure registration and public access settings are as you expect.
6.  Review the user roles in the settings area.
7.  Read the below to further understand the security for images & attachments.

**Multi-Factor Authentication**

Any user can enable multi-factor authentication (MFA) on their account. Upon login they would then need to use an extra proof of identity to gain access. BookStack currently supports the following mechanisms:

*   TOTP (Time-based One-Time Passwords)
    *   Labelled as “Mobile App” (Google/Microsoft Authenticator etc…).
    *   Uses a SHA1 algorithm internally (Greater algorithms have poor cross-app compatibility).
*   Backup Codes
    *   These are a list of 16 one-time-use codes.
    *   Users will be warned once they have less than 5 codes remaining.

Secrets and values for these options are stored encrypted within the database.

Where required, MFA can be forced upon users via their roles. This can be found via a “Requires Multi-Factor Authentication” checkbox seen when editing a role. If a user does not already have an MFA method configured, they will be forced to set one up upon next login.

**Securing Images**

By default, Images are stored in a way which is publicly accessible which ensures performance while using BookStack. Listed below are a few options for increasing image security.

**Alternative Storage Options**

Review our file upload storage options documentation for image storage options that add addition access or permission control to image requests.

**Complex Urls**

In the settings area of BookStack you can find the option ‘Enable higher security image uploads?’. Enabling this will add a 16 character random string to the name of image files to prevent easy guessing of URLs. This increases security without potential performance concerns.

**Prevent Directory Indexes**

It’s important to ensure you disable ‘directory indexes’ to prevent unknown users from being able to navigate their way through your images. Here’s the configuration for NGINX & Apache if your server allows directory indexes:

**NGINX**

    1
    2
    3
    4
    5
    

    # By default indexes are disabled on Nginx but if you have them enabled
    # add this to your BookStack server block
    location /uploads {
           autoindex off;
    }
    

**Apache**

    1
    2
    3
    4
    5
    

    # Add this to your Apache BookStack virtual host if Indexes are enabled.
    # If .htaccess file are enabled then the below should already be active.
    <Location "/uploads">
        Options -Indexes
    </Location>
    

You can test that indexes are disabled by attempting to navigate to <your_bookstack_url>/uploads/images in the browser after having uploaded at least one image. You should not see a list of files but instead a BookStack “Not Found” page.

**Attachments**

Attachments, if not using Amazon S3, are stored in the storage/uploads directory. By default, unlike images, these are stored behind the application authentication layer so access depends on permissions you have set up at a role level and page level.

If you are using Amazon S3 for file storage then access will depend on your S3 permission settings. Unlike images, BookStack will not automatically attempt to make uploaded attachments publically accessible.

**User Passwords**

User passwords, if not using an alternative authentication method, are stored in the database. These are hashed using the standard Laravel hashing methods which use the Bcrypt hashing algorithm.

**JavaScript in Page Content**

By default, JavaScript tags within page content is escaped when rendered. This can be turned off by setting ALLOW_CONTENT_SCRIPTS=true in your .env file. Note that even if you disable this escaping the WYSIWYG editor may still perform it’s own JavaScript escaping. This option will also alter the CSP rules set by BookStack.

_**This option disables some fundamental cross-site-scripting protections. Only use this option on secure instances, where only very trusted users can edit content**_

**Web Crawler Control**

The rules found in the /robots.txt file are automatically controlled via the “Allow public viewing?” setting. This can be overridden by setting ALLOW_ROBOTS=false or ALLOW_ROBOTS=true in your .env file. If you’d like to customise the rules this can be done via theme overrides.

**Secure Cookies**

BookStack uses cookies to track sessions, remember logins and for XSRF protection. When using HTTPS you may want to ensure that cookies are only sent back to the browser if the connection is over HTTPS. If you have set a https APP_URL option in your .env this will enabled automatically but it can also be forced on by setting SESSION_SECURE_COOKIE=true in your .env file.

**Host Iframe Control**

By default BookStack will only allow itself to be embedded within iframes on the same domain as you’re hosting on. This is done through a CSP: frame-ancestors header. You can add additional trusted hosts by setting a ALLOWED_IFRAME_HOSTS option in your .env file like the example below:

    1
    2
    3
    4
    5
    

    # Adding a single host
    ALLOWED_IFRAME_HOSTS="https://example.com"
    
    # Multiple hosts can be separated with a space
    ALLOWED_IFRAME_HOSTS="https://a.example.com https://b.example.com"
    

Note: when this option is used, all cookies will served with SameSite=None (info) set so that a user session can persist within the iframe.

**Iframe Source Control**

By default BookStack will only allow certain other hosts to be used as src values for embedded iframe/frame content within the application. This is done through a CSP: frame-src header. You can configure the list of trusted sources by setting a ALLOWED_IFRAME_SOURCES option in your .env file like the examples below:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    

    # Adding a single host
    ALLOWED_IFRAME_SOURCES="https://example.com"
    
    # Multiple hosts can be separated with a space
    ALLOWED_IFRAME_SOURCES="https://a.example.com https://b.example.com"
    
    # Allow all sources
    # This opens vulnerability risk and should only be done in secure & trusted environments.
    ALLOWED_IFRAME_SOURCES="*"
    

By default this option is configured as follows:

    1
    

    ALLOWED_IFRAME_SOURCES="https://*.draw.io https://*.youtube.com https://*.youtube-nocookie.com https://*.vimeo.com"
    

Note: The source of ‘self’ will always be automatically added to this CSP rule. In addition, the host used for the diagrams.net integration (If enabled) will be automatically appended to the lists of hosts.

**Failed Access Logging**

An option is available to log failed login events to a log file which is useful to identify users having trouble logging in, track malicious login attempts or to use with tools such as Fail2Ban. This works with login attempts using the default email & password login mechanism or attempts via LDAP login. Failed attempts are **not logged** for “one-click” social or SAML2 options.

To enable this you simply need to define the LOG_FAILED_LOGIN_MESSAGE option in your .env file like so:

    1
    

    LOG_FAILED_LOGIN_MESSAGE="Failed login for %u"
    

The optional “%u” element of the message will be replaced with the username or email provided in the login attempt when the message is logged. By default messages will be logged via the php error_log function which, in most cases, will log to your webserver error log files.

**Untrusted Server Side Requests**

Some features, such as the PDF exporting, have the option to make http calls to external user-defined locations to do things such as load images or styles. This is disabled by default but can be enabled if desired. This is required for using WKHTMLtoPDF as your PDF export renderer. This should only be enabled in BookStack environments where BookStack users and viewers are fully trusted.

To enable untrusted server side requests, you need to define the ALLOW_UNTRUSTED_SERVER_FETCHING option in your .env file like so:

    1
    

    ALLOW_UNTRUSTED_SERVER_FETCHING=true
    

**Content Security Policy (CSP)**

BookStack serves responses with a CSP header to increase protection again malicious content. This is especially important in a system such as BookStack where users can create a variety of HTML content, especially so if you allow untrusted users to create content in your instance. The CSP rules set by BookStack are as follows:

*   frame-ancestors 'self'
    *   Restricts what websites can embed BookStack pages via iframes.
    *   See the “Host Iframe Control” section above for details on expanding this rule to other hosts.
*   frame-source 'self' https://*.diagrams.net https://*.draw.io https://*.youtube.com https://*.youtube-nocookie.com https://*.vimeo.com https://embed.diagrams.net
    *   Restricts what sources are allowed to load for frames/iframes.
    *   Can be configured via a ALLOWED_IFRAME_SOURCES .env option.
    *   May be different depending on other configuration set.
*   script-src http: https: 'nonce-abc123' 'strict-dynamic'
    *   Restricts what scripts can be ran on a BookStack-served page.
    *   Will not be set if the ALLOW_CONTENT_SCRIPTS .env option is active.
    *   The nonce value used is randomly generated upon each request. It is automatically applied to any “Custom HTML Head Content” scripts.
*   object-src 'self'
    *   Restricts which embeddable content can be loaded onto a BookStack-served page.
    *   Will not be set if the ALLOW_CONTENT_SCRIPTS .env option is active.
*   base-uri 'self'
    *   Restricts what <base> tags can be added to a BookStack-served page.

If needed you should be able to set additional CSP headers via your webserver. If there’s a clash with an existing BookStack CSP header then browsers will generally favour the most restrictive policy.

**MySQL SSL Connection**

If your BookStack database is not on the same host as your web server, you may want to ensure the connection is encrypted using SSL between these systems. Assuming SSL is configured correctly on your MySQL server, you can enable this by defining the MYSQL_ATTR_SSL_CA option in your .env file like so:

    1
    2
    3
    4
    5
    

    # Path to Certificate Authority (CA) certificate file for your MySQL instance.
    # When this option is used host name identity verification will be performed
    # which checks the hostname, used by the client, against names within the
    # certificate itself (Common Name or Subject Alternative Name).
    MYSQL_ATTR_SSL_CA="/path/to/ca.pem"
    

**Using BookStack Content Externally**

In some scenarios you may use BookStack user-provided content externally (Accessed via the database or API). Such content is not guaranteed to be safe so keep security in mind when dealing with such content. In some cases, the system will apply some filtering to content in an attempt to prevent certain vulnerabilities, but this is not assured to be a bullet-proof defence.

Within its own interfaces, unless disabled, BookStack makes use of Content Security Policy (CSP) rules to heavily negate cross-site scripting vulnerabilities from user content. If displaying user content externally, it’s advised you also use defences such as CSP or other techniques such as disabling of JavaScript entirely.

CVE-2022-40690: Security ·  BookStack

Hello everyone! This episode will be about the new hot twenty vulnerabilities from CISA, NSA and FBI, Joint cybersecurity advisory (CSA) AA22-279A, and how I analyzed these vulnerabilities using my open source project Vulristics. Alternative video link (for Russia): https://vk.com/video-149273431_456239105 Americans can’t just release a list of “20 vulnerabilities most commonly exploited in attacks on […]

Hello everyone! This episode will be about the new hot twenty vulnerabilities from CISA, NSA and FBI, Joint cybersecurity advisory (CSA) AA22-279A, and how I analyzed these vulnerabilities using my open source project Vulristics.

Alternative video link (for Russia): https://vk.com/video-149273431\_456239105

Americans can’t just release a list of “20 vulnerabilities most commonly exploited in attacks on American organizations.” They like to add geopolitics and point the finger at some country. Therefore, I leave the attack attribution mentioned in the advisory title without comment.

But I like such lists of vulnerabilities for a number of reasons:

*   Such lists of **vulnerabilities** show which CVEs need to be addressed. This is the most obvious. If you notice vulnerabilities from the list in your infrastructure, start fixing them as soon as possible.
*   Such lists of vulnerabilities show the **software and hardware products** that are most important to monitor. This means that your vulnerability scanner must support this software very well. Make sure you can verify this.
*   Such lists of vulnerabilities show **groups of software and hardware products** that need to be monitored first. Usually these are products that are available to a wide range of users and are inconvenient to upgrade.
*   Such lists of vulnerabilities show **the types of vulnerabilities** that you need to pay attention to first.
*   Such lists of vulnerabilities are relatively compact and **can be easily analyzed** even manually.

I can’t help but notice that the quality of the advisory is not very high. For example, the description of vulnerabilities was automatically taken from NVD. Including this:

“Microsoft Exchange Server remote code execution vulnerability. This CVE ID differs from CVE-2021-26412, CVE-2021-26854, CVE-2021-26855, CVE-2021-26858, CVE-2021-27065, and CVE-2021-27078”.

Not very informative, right? This joint advisory was released by three big serious organizations. They could work harder and write a unique text for each of the 20 CVEs. But no one seems to care.

Here is a list of all vulnerabilities from the advisory:

1.  Apache Log4j CVE-2021-44228 Remote Code Execution
2.  Pulse Connect Secure CVE-2019-11510 Arbitrary File Read
3.  GitLab CE/EE CVE-2021-22205 Remote Code Execution
4.  Atlassian CVE-2022-26134 Remote Code Execution
5.  Microsoft Exchange CVE-2021-26855 Remote Code Execution
6.  F5 Big-IP CVE-2020-5902 Remote Code Execution
7.  VMware vCenter Server CVE-2021-22005 Arbitrary File Upload
8.  Citrix ADC CVE-2019-19781 Path Traversal
9.  Cisco Hyperflex CVE-2021-1497 Command Line Execution
10.  Buffalo WSR CVE-2021-20090 Relative Path Traversal
11.  Atlassian Confluence Server and Data Center CVE-2021-26084 Remote Code Execution
12.  Hikvision Webserver CVE-2021-36260 Command Injection
13.  Sitecore XP CVE-2021-42237 Remote Code Execution
14.  F5 Big-IP CVE-2022-1388 Remote Code Execution
15.  Apache CVE-2022-24112 Authentication Bypass by Spoofing
16.  ZOHO CVE-2021-40539 Remote Code Execution
17.  Microsoft CVE-2021-26857 Remote Code Execution
18.  Microsoft CVE-2021-26858 Remote Code Execution
19.  19) Microsoft CVE-2021-27065 Remote Code Execution
20.  20) Apache HTTP Server CVE-2021-41773 Path Traversal

Of course, I did not deny myself the pleasure of using this list of CVEs as input for my Vulristics vulnerability prioritization tool. Just to see how Vulristics handles it and tweak Vulristics if needed.

Here is the command I used to generate the report:

    $ python3.8 vulristics.py --report-type "cve_list" --cve-project-name "AA22-279A" --cve-list-path joint_cves.txt --cve-data-sources "ms,nvd,vulners,attackerkb" --cve-comments-path comments.txt --rewrite-flag "True"

The full report is here: https://avleonov.com/vulristics\_reports/aa22-279a\_report\_with\_comments\_ext\_img.html

**Vulnerable Products**

If you look at the list of vulnerable software and hardware products, then some of them, obviously, should have been included in this advisory. Because lately there have been a lot of publications about how attackers exploit the vulnerabilities in these products:

*   Apache HTTP Server
*   Apache Log4j2
*   GitLab
*   Microsoft Exchange
*   Confluence Server
*   Zoho ManageEngine ADSelfService Plus
*   Pulse Connect Secure

The second group of products. For them, there were also publications about attacks. But it seems that these are more niche products and are less perceived as targets for attackers:

*   BIG-IP
*   Citrix Application Delivery Controller
*   VMware vCenter
*   Cisco HyperFlex HX

And finally, there are quite exotic products that apparently reflect the specifics of American IT:

*   Sitecore Experience Platform (XP)
*   Hikvision Web Server
*   Apache APISIX
*   Buffalo WSR

**Criticality of Vulnerabilities**

Vulristics has identified all vulnerabilities as vulnerabilities of the highest criticality level (Urgent). Vulristics found public exploits for all vulnerabilities.

At the same time, if you look at CVSS, then there is this:

All vulnerabilities: 20  
Critical: 16  
High: 4  
Medium: 0  
Low: 0

So if you are using CVSS for prioritization, don’t forget about the High level vulnerabilities.

**Detected Types of Vulnerabilities**

*   Remote Code Execution
*   Command Injection
*   Arbitrary File Reading
*   Authentication Bypass
*   Path Traversal

As we can see, all vulnerabilities are obviously critical except for one “Path Traversal”:

Path Traversal – Citrix Application Delivery Controller (CVE-2019-19781)

The description of the vulnerability leaves no room for detecting another type:

“An issue was discovered in Citrix Application Delivery Controller (ADC) and Gateway 10.5, 11.1, 12.0, 12.1, and 13.0. They allow Directory Traversal”.

The same type is indicated in the advisory AA22-279A: Citrix ADC CVE-2019-19781 Path Traversal

And only in the description of the exploit we can see that this is in fact RCE: “This tool exploits a directory traversal bug within Citrix ADC (NetScalers) which calls a perl script that is used to append files in an XML format to the victim machine. This in turn allows for **remote code execution**.”

Well, this is another reminder to us that we should not do hard filtering by vulnerability type. It’s also not a good idea to trust the description from NVD. The type of vulnerability may change over time, and no one will make changes to the description in NVD.

In some cases, Vulristics can help to more accurately determine the type of vulnerability:

AA22-279A: Apache HTTP Server CVE-2021-41773 Path Traversal  
Vulristics: Remote Code Execution – Apache HTTP Server (CVE-2021-41773)

Why? Because we can read in the description: “If CGI scripts are also enabled for these aliased pathes, this could allow for **remote code execution**.”

But of course Vulristics is not a silver bullet. It is difficult to come up with something here other than manual analysis of publications about vulnerabilities and exploits.

I also cannot help but point out that for some of the vulnerabilities, Vulrisitcs determined the types of vulnerabilities more correctly in accordance with the description:

AA22-279A: GitLab CE/EE CVE-2021-22205 Remote Code Execution  
Vulristics: Command Injection – GitLab (CVE-2021-22205) – Urgent \[947\]  
“… which resulted in a **remote command execution**.”

AA22-279A: Sitecore XP CVE-2021-42237 Remote Code Execution  
Vulristics: Command Injection – Sitecore Experience Platform (XP) (CVE-2021-42237)  
“… it is possible to achieve **remote command execution** on the machine.”

AA22-279A: VMware vCenter Server CVE-2021-22005 Arbitrary File Upload  
Vulristics: Remote Code Execution – VMware vCenter (CVE-2021-22005)  
“…may exploit this issue **to execute code** on vCenter Server by uploading a specially crafted file.”

AA22-279A: F5 Big-IP CVE-2022-1388 Remote Code Execution  
Vulristics: Authentication Bypass – BIG-IP (CVE-2022-1388)  
… undisclosed requests **may bypass** iControl REST **authentication**“

AA22-279A: Apache HTTP Server CVE-2021-41773 Path Traversal  
Vulristics: Remote Code Execution – Apache HTTP Server (CVE-2021-41773)  
“… this could allow for **remote code execution**.”

AA22-279A: Apache CVE-2022-24112 Authentication Bypass by Spoofing  
Vulristics: Remote Code Execution – Apache APISIX (CVE-2022-24112)  
“… is vulnerable to **remote code execution**.”

AA22-279A: Buffalo WSR CVE-2021-20090 Relative Path Traversal  
Vulristics: Authentication Bypass – Buffalo WSR (CVE-2021-20090)  
“… allow unauthenticated remote attackers to **bypass authentication**.”

Therefore, do not rush to trust the vulnerability type from the CISA Known Exploited Vulnerabilities Catalog and take it into account when prioritizing vulnerabilities.

Hi! My name is Alexander and I am a Vulnerability Management specialist. You can read more about me here. Currently, the best way to follow me is my Telegram channel @avleonovcom. I update it more often than this site. If you haven’t used Telegram yet, give it a try. It’s great. You can discuss my posts or ask questions at @avleonovchat.

А всех русскоязычных я приглашаю в ещё один телеграмм канал @avleonovrus, первым делом теперь пишу туда.

Tag

#apache