Silicon Valley vendor tackles command injection and MitM-to-RCE issues

Adam Bannister 16 September 2022 at 16:10 UTC  
Updated: 16 September 2022 at 16:11 UTC

Silicon Valley vendor tackles command injection and MitM-to-RCE issues

Vulnerabilities in a third-party module within the firmware of NETGEAR routers and Orbi WiFi Systems could lead to arbitrary code execution on affected devices.

The component in question is FunJSQ, “a third-party gaming speed-improvement service” developed by China-based Xiamen Xunwang Network Technology, included in NETGEAR firmware images, according to a security advisory published yesterday (September 15) by European IoT security firm ONEKEY.

Now patched, the high severity flaws included an unauthenticated command injection flaw (CVE-2022-40619), and an insecure auto-update mechanism (CVE-2022-40620) that enabled manipulator-in-the-middle (MitM) attacks, potentially leading to remote code execution (RCE).

Read more of the latest hardware security news

The issues, which were both given a CVSS score of 7.7, can only be exploited if an attacker has the victim’s WiFi password or access to an Ethernet connection to the router, according to a NETGEAR advisory.

Moreover, ONEKEY indicated that FunJSQ is seemingly only enabled when the Quality of Service (QoS) feature, which prioritizes internet traffic for applications like VoIP or online gaming, is also activated.

**Insecure auto-update**

The insecure auto-update mechanism led to arbitrary code execution from the WAN interface due to a trio of issues.

First, insecure communications arose from the “explicit disabling of certificate validation (-k), which allows us to tamper with data returned from the server”, according to ONEKEY researchers.

Second, the “update packages are simply validated via a hash checksum, packages are not signed in any way”.

And finally, “arbitrary extraction to the root path with elevated privilege \[allowed\] whoever controls the update package to overwrite anything anywhere on the device (which puts a lot of trust in a third party supplier)”.

**Command injection**

The command injection issue was discovered during an investigation of , which was exposed by HTTP server .

This endpoint accepted parameters that required an authentication token generated by a weak algorithm that used a hardcoded string and the device MAC address.

The resulting token was sent to a remote FunJSQ service for validation by curl.

“We found that the curl command line is built using the value, which is user controlled and unsanitized prior to creating the full command line,” revealed the researchers.

**Coordinated disclosure**

ONEKEY reported the bug to NETGEAR on May 19, and the Silicon Valley vendor disclosed details of the flaw alongside firmware updates on September 9.

Affected router models include R6230, R6260, R7000, R8900, R9000, and XR300, while the vulnerable Orbi WiFi Systems models are RBR20, RBS20, RBR50, and RBS50.

ONEKEY said the research highlighted the supply chain threat posed by “undocumented and vulnerable software components in widely deployed embedded devices”.

The researchers urged vendors to “assure that all included third-party vendors adhere to at least the same cybersecurity standards” as their own.

YOU MIGHT ALSO LIKE WAPPLES web application firewall faulted for multiple flaws

NETGEAR resolves router vulnerabilities in bundled gaming component

Social engineering attack compromises internal networks and Uber’s bug bounty reports

John Leyden 16 September 2022 at 15:26 UTC  
Updated: 16 September 2022 at 15:29 UTC

Social engineering attack compromises internal networks and Uber’s bug bounty reports

Uber is investigating claims its systems have been compromised by an attacker.

The attacker offered evidence that they had successfully breached many of the ride-sharing app firm’s internal networks by posting various screenshots and commenting on their exploits in interactions with the media and security experts.

The miscreant claimed that they socially engineered an employee before gaining access to their VPN credentials. This compromised access subsequentially allowed them to hack into its network and scan Uber’s intranet.

Catch up with the latest data breach news

Uber is purported to rely on multi-factor authentication (MFA). Third-party experts have commented that an attacker may have been able to circumvent these controls by establishing a fake domain and any relaying authentication codes submitted to the genuine domain using a manipulator-in-the-middle (MitM) attack.

According to the attacker, the hack was set up by spamming an Uber employee with push authentication requests for more than an hour before using another channel to trick them into authorizing one of the requests.

The attacker claims they went on to locate a network share containing powershell scripts that included the username and password of a system administrator.

Using this information, the cybercrook was purportedly able to extract passwords and access Uber’s AWS (Amazon Web Services), Onelogin, and GSuite environments, among others).

They also hacked into an Uber employee’s HackerOne account before commenting on multiple tickets, evidence that the miscreant likely has compromised highly sensitive bug bounty reports related to security vulnerabilities in Uber products and infrastructure.

As a result of the hack, Uber workers have been left unable to access Slack and some other tools. In addition, the hacker posted NSFW (Not Safe For Work) images on internal employee resource pages.

In an update to its official Twitter account, Uber said: “We are currently responding to a cybersecurity incident. We are in touch with law enforcement and will post additional updates here as they become available.”

The Daily Swig asked for early access to comment on the results of this ongoing data breach investigation. No word back as yet but we’ll update this story as and when more information comes to hand.

DON’T FORGET TO READ ManageEngine flaw posed code injection risk for password management software

Uber hack linked to hardcoded secrets spotted in powershell script

Bug spawned by parsing problem in upstream package

Adam Bannister 15 September 2022 at 15:48 UTC

Bug spawned by parsing problem in upstream package

The maintainers of venerable open source content management system (CMS) TYPO3 have fixed a cross-site scripting (XSS) flaw with a raft of software updates.

The XSS mechanism of PHP package typo3/html-sanitizer was bypassed due to a parsing problem in upstream package masterminds/html5, whereby a “malicious markup used in a sequence with special HTML comments cannot be filtered and sanitized”, explained a GitHub advisory published on Tuesday (September 13).

The issue has been patched in 7.6.58, 8.7.48, 9.5.37, 10.4.32, and 11.5.16 of typo3/cms-core. All prior versions on these release lines are affected.

DON’T MISS WordPress project WPHash harvests 75 million hashes for detecting vulnerable plugins

With user interaction required the bug is classed as only moderate severity, notching a CVSS score of 6.1.

Nevertheless, even with a modest market share TYPO3 accounts for a huge number of active installations.

Launched in 1997, the free-to-use CMS has 2.43% of the CMS market, which translates to more than 230,000 customers, 46% of which are based in Germany.

The TYPO3 Association, which has around 900 members, funds development via donations and membership subscriptions.

Credit for bug discovery goes to security researcher David Klein, while Oliver Hader, TYPO3 security team lead and core developer, developed the patch.

RECOMMENDED Six-year-old blind SSRF vulnerability in WordPress Core feature could enable DDoS attacks

Open source CMS TYPO3 tackles XSS vulnerability

Researcher uncovers RCE and undocumented backdoor risks

John Leyden 15 September 2022 at 14:43 UTC  
Updated: 15 September 2022 at 14:48 UTC

Researcher uncovers RCE and undocumented backdoor risks

Multiple vulnerabilities in the WAPPLES web application firewall (WAF) created a means to commandeer vulnerable devices and run arbitrary commands, a researcher warns.

Another set of flaws in the technology created a means to access the device with privileges through a “backdoor account”, according to security researcher Konstantin Burov.

More specifically, the Kazakhstan-based security researcher uncovered vulnerabilities in WAPPLES from version 4.0 to 6.0 that allowed a remote attacker to execute arbitrary code or obtain confidential information using predefined credentials, among other exploits.

Burov also discovered that it was possible to escalate user privileges to root in versions 5.0 and 6.0 of the technology.

Catch up on the latest security research and analysis

WAPPLES, from Penta Security Systems, is shipped as either a hardware appliance or a virtual machine. In either scenario, the technology is designed to protect what might otherwise be vulnerable websites or applications against potential attack.

The technology is most widely used in Japan and South Korea, according to Shodan-based searches run by Burov.

The vulnerabilities – tracked as CVE-2022-24706, CVE-2022-31322, CVE-2022-35413, CVE-2022-31324, and CVE-2022-35582 – are documented in a technical blog post.

The most severe, remote code execution (RCE) risk – tracked as CVE-2022–24706 (currently undergoing reanalysis) – arises from reliance on a vulnerable third-party component.

“WAPPLES uses a vulnerable CouchDB version in default configuration that leads to remote OS command execution,” Burov explains. “To exploit this vulnerability the attacker must have access to the management interface.”

Burov warned: “An attacker could gain unprivileged access to a system as a ‘couchdb’ user, then escalate privileges using the other vulnerabilities.”

**Penta-thlon**

Separately, Burov discovered that the “operating system that WAPPLES runs on has a built-in non-privileged user ‘penta’ with a predefined password.

“The password is revealed in the system script and differs for different versions of the product,” according to the researcher.

The practical upshot of this unclosed backdoor (tracked as CVE-2022–35582) is that even moderately skilled attackers might well be able to get hold of device credentials and thereby gain uncontrolled access to the device.

Hardcoded credentials for the web-API of some recent version of WAPPLES were also exposed, Burov discovered. Flaws in WAPPLES undermined the protection it might otherwise be able to offer.

YOU MAY ALSO LIKE Vendor disputes seriousness of firewall plugin RCE flaw

Burov, a security engineer and pen tester, told The Daily Swig that he carried out security research in his spare time.

“My colleagues showed me this product, and I almost immediately found the classic bug of command injection in CLI,” he explained. “And I decided to look under the hood, because I was sure there were more serious bugs.

“I can’t confirm that the issue has been fixed by the vendor as I do not currently have access to the WAPPLES appliance. All I have is vendor assurances.”

After failing to get a response from Penta Security, Burov reached out to Cloudbric Corp, a partner of Penta Security, who told him that the issues had been resolved.

The Daily Swig also approached Penta Security and Cloubric for comment. No word back as yet, but we’ll update this story as soon as more information comes to hand.

Burov said his research findings offered lessons for other software developers.

“If you are incorporating other technologies into your product, you should know it as if it were your own product – e.g in the CouchDB manual, it was described that the default value of Erlang Cookie needs to be changed,” he explained. “I also recommend to study the reference ‘OWASP Secure Coding Practices’.”

RELATED Vulnerability in Xalan-J could allow arbitrary code execution

WAPPLES web application firewall faulted for multiple flaws

John Leyden 13 September 2022 at 14:39 UTC

CRLs are back, baby!

Certificate authority Let’s Encrypt has announced plans to establish a platform that will support the revocation of digital certificates via Certificate Revocation Lists (CRLs).

The CRL approach to disavowing compromised digital identities was established many years ago but has largely phased been out over the last decade or more in favor of the Online Certificate Status Protocol (OCSP), owing to its burdensome impact on performance.

CRLs are comprehensive lists of digital certificates that have been revoked by a certificate authority (CA) before their expiration date, whereas the OSCP enables browsers to consult the CA’s OCSP service over a specific certificate’s status.

**Back in vogue**

The CRL approach has recently become fashionable again – like listening to albums on vinyl – thanks to recent browser security updates.

“By collecting and summarizing CRLs for their users, browsers are making reliable revocation of certificates a reality, improving both security and privacy on the web,” Let’s Encrypt explains in a blog post explaining how it is establishing an infrastructure to better support CRL-based digital certificate revocation.

Catch up on the latest encryption-related news and analysis

Certificates put the ’S’ – security – into HTTPS. Unless a workable certificate revocation system is in place, there’s no remediation for a website owner in cases where an attacker steals the digital certificate of their website.

Without revocation, the compromised credential remains valid until it automatically expires at the end of its lease – most often years after the initial attack.

This undesirable situation is a direct result of the shortcomings in the revocation process that Let’s Encrypt is seeking to address. Powered by changes in browser software and support by Let’s Encrypt, the rejuvenated CRL approach promises an effective mechanism to revoke web certificates once their legitimate owners realize they have been either leaked or stolen – a sadly not infrequent problem.

Digital certificate revocation is therefore less about setting up a secure website in the first place, and more about making your website secure again after it’s been hacked.

The Daily Swig asked Let’s Encrypt to comment on whether it was seeking to encourage wider adoption of this approach by other CAs or through standards bodies, among other questions.

No word back as yet, but we’ll update this story as and when more information comes to hand.

In a Twitter thread, web security expert Scott Helme analyzed the merits and potential drawbacks of Let’s Encrypt’s move and the wider advantages and trade-offs inherent in the browser-based CRL approach.

YOU MAY ALSO LIKE LastPass flags security incident after attackers stole source code, technical information

Let’s Encrypt builds infrastructure to support browser-based certificate revocation revival

Open source project is used by various SAML implementations

Jessica Haworth 12 September 2022 at 14:46 UTC

Open source project is used by various SAML implementations

  

A vulnerability in Xalan-J, an Apache project used by multiple SAML implementations, could allow arbitrary code execution, researchers warn.

XSLT (Extensible Stylesheet Language Transformations) is a markup language that can transform XML documents into other formats, such as HTML.

Xalan-J is a Java version implementation of an XSLT processor.

The project is vulnerable to an integer truncation issue when processing malicious XSLT stylesheets, discovered by Google Project Zero’s Felix Wilhelm.

Read more of the latest news about web security vulnerabilities

This issue can be used to corrupt Java class files generated by the internal XSLTC compiler and execute arbitrary Java bytecode, he warned, allowing for arbitrary code execution in software using Xalan-J for processing untrusted XSLT stylesheets.

As Xalan-J is used for performing XSLT transformations during XML signature verification in OpenJDK, this bug potentially affects a large number of Java-based SAML implementations, Wilhelm warned.

SAML is a method of authentication that enables a user to access multiple web applications using one set of login credentials.

**Mitigations**

The researcher noted that XSLT support for XML signatures can be disabled using the property, however the default value for applications running without a SecurityManager was false until JDK 17, “so I would expect a lot of implementations to be vulnerable to this”.

In a blog post published in August, Wilhelm said that he was able to write a Proof-of-Concept (PoC) exploit for this bug “that generates a valid (but useless) class file that’s almost completely controlled by the attacker”.

He continued: “While I haven’t successfully executed my own bytecode yet I’m very confident that this is possible with a bit more time investment, so I am reporting this issue now and may follow-up with a more complete proof-of-concept at a later stage.”

Another researcher has since produced their own PoC for the vulnerability, more details of which can be found on GitHub.

The vulnerability has since been fixed in OpenJDK, the open source implementation of the Java Standard Edition (Java SE) and Java Development Kit (JDK).

Wilhelm notes that it has not been fixed in Apache’s version, which is being retired.

RECOMMENDED ManageEngine vulnerability posed code injection risk for password management software

Vulnerability in Xalan-J could allow arbitrary code execution

Project mission is to crowdsource the indexing and curating of plugin bug data

Adam Bannister 12 September 2022 at 11:04 UTC

Project mission is to crowdsource the indexing and curating of plugin bug data

An open source project designed to help security researchers fingerprint WordPress Plugins is seeking feedback and contributors.

Currently in beta mode, WPHash is a free-to-use web service that helps security professionals identify installed plugins and whether they contain security vulnerabilities.

To this end, it indexes 75 million SHA256 hashes for WordPress plugins – covering the vast majority available on the WordPress marketplace, along with their various versions.

The project mission is “to crowd-source the indexing and curating of WordPress plugin vulnerability data”.

**Enumeration and fingerprinting**

“WPHash’s main purpose is to provide security researchers with additional tooling in the form of a web service, which helps them in the enumeration and fingerprinting of installed WordPress plugins,” Dave Miller, WPHash architect and security engineer at Swiss IT security company Cyllective, tells The Daily Swig.

The WPHash website comprises an alphabetical index of hashes, a search function for this index, an experimental OpenAPI spec for looking up hashes and filepaths, and FAQs. Both original and normalized SHA256 checksums are indexed.

Catch up with the latest WordPress security news

“Researchers can query WPHash for known filepaths of the plugin they’re after,” says Miller. “Then, they request these filepaths on the target and calculate the SHA256 hash, which they then use to lookup plugin metadata on WPHash. This process allows them to determine exact plugin versions, and with further investigation determine if the plugin is vulnerable.”

Indexed vulnerabilities can be queried via WPHash or in researchers’ own tooling by using the raw data available on the WPHash GitHub repo.

Miller has said on Reddit that WPHash is not intended to be a direct competitor to Automattic WordPress security scanner WPScan, whose vulnerability data and tooling he concedes is currently “more curated and more complete”.

Nevertheless, WPScan fulfils Miller’s preference for freely accessing crowdsourced vulnerability information “in my own tooling without being stuck with API rate limits”.

**Call for contributors**

The scope of future development for WPHash partly hinges on the level of community support Miller can attract. At the very least, he is “dedicated to keep operating WPHash for free and try to keep improving both the REST API as well as the data behind it”.

A number of retweets on Twitter and upvotes on Reddit have signalled support for the project, suggests Miller, who hopes to enlist some co-contributors from the open source community “once people start playing around with WPHash and its data. I think I need to make it easier and start writing contribution guides to get more people involved.”

Anyone who wishes to contribute, field questions, or offer feedback to WPHash can do so by contacting Miller via his Twitter account.

Cyllective, which published a blog post documenting its research into plugin vulnerabilities in May, is sponsoring the project.

RECOMMENDED Graph-based JavaScript bug scanner discovers more than 100 zero-day vulnerabilities in Node.js libraries

WordPress project WPHash harvests 75 million hashes for detecting vulnerable plugins

Issue present in pingback requests feature

Issue present in pingback requests feature

  

Researchers have gone public with a six-year-old blind server-side request forgery (SSRF) vulnerability in a WordPress Core feature that could enable distributed denial-of-service (DDoS) attacks.

In a blog post published this week (September 6), Sonar researchers detailed how they were able to exploit a vulnerability in the pingback requests feature within WordPress.

The vulnerability first surfaced in 2017, yet remains unpatched.

**Pingback problem**

Pingback requests allow WordPress authors to be notified when another website links to their blog.

The pingback functionality is exposed on the XMLRPC API, which can be accessed through the file. Using this method, other blogs can announce pingbacks.

Read more of the latest news about web security vulnerabilities

This feature could enable attackers to perform DDoS attacks by maliciously asking thousands of blogs to check for pingbacks on a single victim server, Sonar researchers explained.

Although pingbacks can be turned off via a checkbox, they are still enabled by default on WordPress instances.

It’s worth noting, the researchers pointed out, that they “couldn’t generically identify ways to leverage this behavior to take over vulnerable instances without relying on other vulnerable services”.

Rather, the bug could ease the exploitation of other vulnerabilities in the affected organization’s internal network.

**Bypassing restrictions**

Thomas Chauchefoin, vulnerability researcher at Sonar and author of the blog, told The Daily Swig: “In 2012, the risks around the pingback feature started to be known, and the WordPress maintainers introduced restrictions on the destination of such requests: they would be limited to a restricted set of ports, only public IP addresses, etc.

“In essence, our finding allows getting around some of these restrictions and targeting hosts from the local network. Attackers could use it to send requests to hosts that wouldn’t have been reachable otherwise, for instance, to exploit a vulnerability in internal services.”

He added: “This bug is in the lineage of most CVEs related to pingbacks, but the oldest indicator of a researcher documenting how to get around this specific restriction is from 2017.”

DON’T MISS WordPress warning: 140k BackupBuddy installations on alert over file-read exploitation

SonarSource researchers disclosed the issue to WordPress on January 21. It was acknowledged as a duplicate bug, according to Sonar, which was reported to the WordPress team in January 2017.

Chauchefoin added: “We reported the vulnerability on January 21 through the official channels, with a pretty standard 90-day disclosure policy. After agreeing to a 30-day extension period, we reviewed a first patch still waiting to be merged upstream. Our publication occurs 228 after our initial report.”

A WordPress Security Team spokesperson told The Daily Swig: “As identified in the Sonar blog post, this is a low-impact issue and exploiting it requires ‘\[chaining\] it to additional vulnerabilities in third-party software’.

“As such, the Security Team considers the issue a low priority.”

They added: “Because of its low severity, the team is discussing whether this issue could be fixed in public as a general hardening measure.”

**Mitigation advice**

WordPress told The Daily Swig that exploiting the bug requires “vulnerabilities in multiple systems outside of WordPress”, but that it recommends website owners always use the DNS servers provided by their hosting provider.

They added: “For the pingbacks, users can turn off pingbacks. The XMLRPC endpoint will only make the HTTP requests (detailed in the Sonar blog post) if pingbacks are open for the post being pinged.

“Website owners can (a) turn off pingbacks globally using the code snippet provided in the original post and/or (b) turn off pingbacks for their blog posts.”

Chauchefoin added: “Going public with unpatched bugs is exceptional for us and was a carefully considered decision. As we had proof that our finding collided with previous public work and that it would require significant work to weaponize against real-world environments, we believe that withholding details any longer would only disadvantage defenders.

“We would like to salute the efforts of the WordPress maintainers; even if we couldn't reach the best outcome possible, backporting fixes for the software behind 40% of all websites is not trivial!”

**Previous pingback issue**

Another vulnerability in the pingback requests feature that allowed DDoS attacks was fixed by WordPress core in 2012.

The issue, reported by Acunetix, could be abused in multiple ways, researchers reported, and was fixed “as a public hardening ticket” in WordPress Core version shortly after discovery.

RECOMMENDED Vendor disputes seriousness of firewall plugin RCE flaw

Six-year-old blind SSRF vulnerability in WordPress Core feature could enable DDoS attacks

Authentication-free flaw opened the door to a raft of exploits

Emma Woollacott 09 September 2022 at 12:46 UTC  
Updated: 09 September 2022 at 15:28 UTC

Authentication-free flaw opened the door to a raft of exploits

UPDATED A vulnerability in ManageEngine could allow an attacker to execute arbitrary code on affected installations of some of its password and access management tools.

ManageEngine offers enterprise IT management software for service management, operations management, Active Directory, and security, and is used by 280,000 organizations in 190 countries.

Thanks to the use of a vulnerable version of Apache OFBiz, a Java-based open source enterprise resource planning (ERP) system, remote attackers could have executed arbitrary code on vulnerable installations of Password Manager Pro, access management tool PAM360, and Access Manager Plus, according to a researcher using the name viniciuspereiras.

Catch up on the latest security research news

No authentication would have been needed to exploit this vulnerability in Password Manager Pro or PAM360 products. In the case of Password Manager Pro, an attacker would be able to enter internal networks, compromise data on the server, or crash or shutdown the whole server and applications.

The vulnerable version of Apache OFBiz, dating back to 2020, exposes an XMLRPC endpoint, which is unauthenticated as authentication is only applied on a per-service basis.

However, when the XMLRPC request is processed before authentication, any serialized arguments for the remote invocation are deserialized.

This, according to the researcher, means that if the classpath contains any classes that can be used as gadgets to achieve remote code execution (RCE), an attacker would be able to run arbitrary system commands on any OfBiz server with the same privileges as the servlet container running OfBiz.

The issue – tracked as CVE-2020-9496 – was reported to ManageEngine on 21 June, and it was acknowledged the same day. The vulnerability was resolved in a new release issued three days later.

"I’d like to thank the security community, although I can’t disclose vulnerability information, there were some researchers who managed to go after it and come up with a working poc \[proof of concept\], exploits and Metasploit modules," the blog post reads.

This article has been updated to include clarifications.

RELATED LastPass flags security incident after attackers stole source code, technical information

ManageEngine vulnerability posed code injection risk for password management software

pfSense and sensibility

Security researchers from IHTeam have uncovered a serious vulnerability in a plugin to the pfSense firewall technology.

The affected pfBlockerNG plugin is not installed by default and the problem was, in any case, resolved by a software update published in June.

This is just as well because the underlying flaw created an unauthenticated remote code execution (RCE) as root risk on affected installations, according to IHTeam. The pfSense pfBlockerNG vulnerability is tracked as CVE-2022-31814.

**Root cause analysis**

pfSense is a firewall/router software distribution based on FreeBSD. The open source\-based network firewall technology can be installed on bare metal or as a virtual appliance.

pfBlockerNG is a plugin component available within pfSense that will facilitate allow-listing or deny-listing of entire IP ranges. It is often used to block entire countries from communicating with networks running pfSense, according to researchers, who point out several factors that call particular attention to the problem.

“The vulnerability is a remote command execution exploitable from an unauthenticated perspective and, on top of that, the web server is running with root privileges,” a representation of IHTeam told The Daily Swig.

Read more of the latest network security news

Importantly, the vulnerability is limited to a plugin of pfSense that is not installed by default.

“It is difficult to say how many systems are affected without actively crawling each of the exposed system,” according to IHTeam.

Accordingly to Shodan, there are around 27,000 exposed pfSense machines on the internet. This should not be taken as any indication of the number of vulnerable systems since many will not be running the affected pfBlockerNG plugin, without considering that even vulnerable installations have likely been patched since the software was updated.

In response to a query from The Daily Swig, the developer of pfBlockerNG said: “The only version that was affected is version 2.1.4\_26 and below. This has been patched and can be upgraded in pkg manager. pfBlockerNG-devel is unaffected and is the recommended version to use.”

**Practical impact**

Netgate, which distributes the pfSense firewall, added in response to a related query: “The problem they \[the researchers\] found was in the pfBlockerNG package but had already been addressed in the pfBlockerNG-devel \[latest, cutting edge version of the\] package, which is the version the package maintainer recommends everyone use.”

Netgate stated that for the problem to become exposed “requires access to the web server on the firewall (which should never be open on WAN and is often restricted internally when configured per best practices), the overall practical impact was considered extremely low despite it having a high score in theory.”

IHTeam said that developers are still shipping and allowing users to install between the 2.x branch and the 3.x branch (the -development one).

“The misunderstanding can be easily resolved it they would simply remove the 2.x branch from the available plugin list,” the researchers added.

IHTeam came across the vulnerability in pfBlockerNG during an independent security assessment of what turned out to be a vulnerable version of the product. A technical write-up of the issue was published in a blog post by IHTeam on Monday (September 5).

**Dev lessons**

A researcher from IHTeam, who asked not to be named, told The Daily Swig that the characteristics of the bug offered lessons for other software developers.

The researcher explained: “To avoid these types of vulnerabilities, developers should take extra care while handling user input (not only via direct and requests, but also via input that might be passed in request headers such as , or ).

“All user input should be carefully analysed and sanitised before being passed to the application. This is also valid for other types of attacks such as cross-site scripting (XSS) or SQL injection, not only for command execution,” they added.

RELATED WatchGuard firewall exploit threatens appliance takeover

Source

PortSwigger