jaysona wrote: ↑Tue Jun 09, 2020 12:15 pm
That's the point of marketing, it's called make as much money as possible by stretching facts as much as possible. 2018 was a long time ago in QNAP land and VirtualStation. A lot has been learned about the glue (VirtualStation) used to integrate KVM/QEMU in QTS since then.
CVE entries are only made after public disclosure, CVE public disclosure is the tip of the iceberg. By the time a CVE number is assigned, the horses have long left the barn.
If you start to scratch and dig and the reported QNAP vulnerabilities you will see that the exploits go after the QNAP integration code and not the code of the program/apps that QNAP is integrating.
For example, QNAP writes the cgi code that gets exploited, but the httpd server that suffers the attack due to the poor cgi code is only indirectly exploited.
you mean stuff like this?
Remote Exploit ShellShock Vulnerability CVE-2014-6271: 2 Easy Methods
https://www.pcworld.com/article/2690932 ... -says.htmlShellshock attacks target QNAP's NAS boxes, FireEye says
The security vendor said the attacks are some of the first seen using Shellshock targeting embedded Linux, which QNAP’s devices run, James T. Bennett and J. Gomez of FireEye wrote in a blog post on Wednesday.
“These attacks result in the hackers having a root level remote shell, gaining full access to the contents of the NAS,” they wrote.
Shellshock is a two-decades-old flaw in Bash, a command-line shell processor present in most Unix and Linux systems. Its discovery last week has set off a scramble to assess the potential risk, as it is easy to exploit and gives attackers full control over a vulnerable server.
QNAP warned on Sunday that its Turbo NAS products were vulnerable, advising administrators to disable Web administration, Web server, WebDAV and other applications and services that use a Web-based interface.
FireEye said taking that precaution may not mitigate the threat, as attackers could find another vulnerable entry point into an organization’s systems and laterally move in order to find a NAS device.
The attack tries to get NAS devices to download a script from a remote server. That script then uploads an SSH (secure shell) key to the local authorized_keys file, which allows the hackers to log in without a password in the future, FireEye wrote.
Also installed is an ELF executable, which is a Linux backdoor that provides shell access. FireEye said that file is named “term_x86_64” or “term_i686.” The servers hosting the malware are in the U.S. and Korea.
In some instances, the backdoor listens for a connection on port 58273. The backdoor serves up a shell if a packet is sent with the text “IAMYOURGOD,” FireEye wrote.
https://thehackernews.com/2014/12/malwa ... -hack.htmlThe attack targets a QNAP CGI script, /cgi-bin/authLogin.cgi, a well known vector for Shellshock on QNAP devices," Johannes B. Ullrich, head of the Internet Storm Center at the SANS Institute, wrote in the blog post published Sunday. "This script is called during login, and reachable without authentication. The exploit is then used to launch a simple shell script that will download and execute a number of additional pieces of malware."
https://www.netgate.com/blog/pfsense-an ... ploit.htmlpfSense and the CVE-2014-6271 ("shellshock") bash exploit.
September 25, 2014
By Jim Thompson
tl;dr: If you’re having shell problems I feel bad for you son. I got 99 problems but bash ain’t one.
If you’ve not heard, Stephane Chazelas discovered a vulnerability in bash, related to how environment variables are processed: trailing code in function definitions was executed, independent of the variable name. In many common configurations, this vulnerability is exploitable over the network.
NIST has assigned a CVSS of 10 CVE-2014-6271. POCs are starting to appear.
So the question becomes, “is pfSense® affected?”
The short answer is: Unlikely, though there are three packages which could lead to an exploit. The base system of pfSense does not include bash. Since bash isn’t on the system, the problem is reduced to packages.
Three packages are affected, and only one is commonly used. The affected packages are:
Anyterm – This package contains bash in its binaries which are in the git repo, not a .pbi or .tgz. This package will simply be retired as it is unmaintained and rarely used. We will review all packages, and any which contain binaries which we have not built from source will be removed or re-engineered such that we can compile from source.
Freeswitch-dev – Runs pkg_add for bash. This package is not actively maintained, and can likely be safely removed from the list of packages with minimal community impact.
FreeRADIUS2 – Adds bash via pkg_add using FreeBSD’s 8.3-RELEASE package set if the user activates Mobile-One-Time-Password (varsettingsmotpenable). We’re looking into the best way to fix it.
Mailscanner – Includes bash also, will be fixed shortly.
Given the lack of impact to pfSense software version 2.1.5 or the pfSense 2.2-BETA images, no fix is required, so we don’t plan any release in response to this issue.
UPDATE: Affected packages have been updated or removed. Full details are in the security announcement which was posted this afternoon. -jimp
FreeBSD != Linux, friends.
The base system doesn't include bash, so unless it's being pulled in another way we can't see, pfsense is not affected.
Unless you've loaded one of three packages, there is no bash binary on the system.
The affected packages are:
Anyterm Contains bash in its binaries which are in the git repo(!), not a .pbi or .tgz. We're removing the package entirely from the repo. No archive. It's not worth keeping. Bye bye. I've been ** internally about packages we didn't compile. Now everyone understands why.
Freeswitch-dev Runs pkg_add for bash. Unmaintained package. Could probably be safely removed.
FreeRADIUS2 Adds bash via pkg_add using FreeBSD's 8.3-RELEASE package set if the user activates Mobile-One-Time-Password (varsettingsmotpenable). Commonly used package, though we are unsure if the maintainer is still around. Will be deactivated for 2.0.x but kept for 2.1+. For 2.1 we can either build/host an up-to-date tgz for it to pkg_add to minimize changes to the code in the package or build bash into the .pbi and adjust its paths/code to handle that better. We favor adding it to the PBI so that if it happens in the future we need only build a new PBI as usual.
Overall, not a huge impact.
EDIT: The Mailscanner package includes bash also, and will be fixed shortly.
https://www.reddit.com/r/PFSENSE/commen ... hellshock/Mateh-
Yeah but what he is communicating here is that it doesn't come by default on FreeBSD.bolapara-
This really isn't a BSD vs. Linux thing. Any system with bash installed is vulnerable. There are Linux systems without bash installed by default too.
https://www.cisecurity.org/advisory/a-v ... f-traffic/A Vulnerability in CGI Based Web Products Could Allow For Unauthorized Redirection of Traffic
A vulnerability has been discovered in a wide variety of Common Gateway Interface (CGI) based web products, which could allow for unauthorized redirection of traffic. This vulnerability exists due to a flaw in the use of the HTTP Proxy environment variable. This vulnerability can be exploited to perform remote man in the middle attacks, cause Denial of Service (DoS) conditions on the affected server, or leverage the affected server to perform Distributed Denial of Service (DDoS) attacks on a third party target.
Many applications and systems with a reliance on CGI or CGI-like environments are affected Apache|Drupal|Go|IIS|NGINX|PHP|Python
A vulnerability has been discovered in a wide variety of CGI-based web products, which could allow for unauthorized redirection of traffic. This vulnerability exists due to a flaw in the use of the HTTP Proxy environment variable.This vulnerability can be exploited when application code is running on CGI or a CGI-like server. HTTP request headers are merged into a specific variable under keys beginning with HTTP. This information is what getenv reads from. When a user submits a request that contains a Proxy header, the header appears to the application as getenv('HTTP_PROXY'). Some common application libraries are trusting this value, even when run in a CGI/SAPI environment.
This vulnerability can be exploited to perform remote man in the middle attacks, cause Denial of Service (DoS) conditions on the affected server, or leverage the affected server to perform Distributed Denial of Service (DDoS) attacks on a third party target.
We recommend the following actions be taken:
· Block the Proxy header for applications running PHP or CGI.
· Apply appropriate patches provided by vendors immediately after appropriate testing.
· Verify no unauthorized system modifications have occurred on system before applying the patch.
· Run all software as a non-privileged user (one without administrative privileges) to diminish the effects of a successful attack.
· Apply the principle of Least Privilege to all systems and services.
https://www.securezoo.com/2020/05/450k- ... abilities/
https://portswigger.net/daily-swig/shie ... y-released
so you are saying these kinds of attack still works even if you don't expose/port forward your pfsense vm router (via virtual station)?