Author: Ta-Lun Yen
Overview
QNAP’s Network Attached Storage (NAS) is a long-time victim of botnet and ransomware attacks – most notably, the recent QLocker attack. According to QNAP’s security advisory, the attack was based on exploiting a vulnerability within Hybrid Backup Sync 3, which is an application that provides duplication and backup functionality between local, remote, and cloud storage. We haven’t yet identified the exact vector being used by the QLocker ransomware.
However, we’ve found another vulnerability ([1] [2]) in our process of determining those vectors, and had a grasp on how device fragmentation will affect a vendor’s ability to build secure software. TXOne’s documentation on this vulnerability can be found here, and I’ll be giving a talk with more information about this vulnerability at Code Blue on October 19th – more info on that here.
CVE-2021-28809: Technical Analysis
On QNAP NAS with legacy QTS (<4.3), with HBS3 installed, there will be a program called rr2 running on port 8899/tcp. The program handles commands sent by another HBS3 instance, and then implements some of the commands that are essential for setting up sync between two QNAP NASes (e.g. list directories). Because all actions in rr2 including login are implemented as commands, it is imperative to check for authorization before any further steps can be conducted. However, in a certain branch of HBS3, there is no check for authorization between commands.
While starting the server, this rr2 program is started via Python WSGI.
The commands are passed through handlers as shown in the following image. Note that there are no checks for authorization included in the process. One can craft packets similar to those a rr2 client would normally send, and by so doing call any handlers without authorization.
QNAP: Device Fragmentation
We then discovered that our point of exploit does not work on some of the QNAP NAS we’ve tested. This vendor is facing the challenge of severe device fragmentation – they have 4 different versions of the code being released as different forms of the software, which means that if they want to patch a single vulnerability they need to patch it 2-4 times instead depending on how the vulnerability shows up in different versions. In the case of Hybrid Backup Sync 3, they have two different major versions of the software which are in turn split up into the ‘legacy’ and ‘mainstream’ versions. Though the code has many differences, they’re both maintained and labeled as ‘HBS3’.
HBS3 Versions
- x86-based device
- Legacy QTS (<4.5)
- Mainstream QTS (>=4.5)
- ARM-based device
- Legacy QTS (<4.5)
- Mainstream QTS (>=4.5)
At worst, there will be 4 different code branches. This will greatly affect a vendor’s ability to respond quickly to security issues, and will add significant complexity to the process of securing an ecosystem that includes the application.
Mitigation
If possible, asset owners running QNAP NAS should update to the latest patch.
Operations that are using strict firewalling or network segmentation, as can be deployed with TXOne Networks’ EdgeFire, can secure this vulnerability without applying the latest patch, however we still advise updating when possible and reviewing the security of QNAP NAS carefully.
Rule information to secure this vulnerability with TXOne’s Edge series (EdgeFire, EdgeIPS, EdgeIPS Pro) can be found here.
Conclusion
QLocker is merely the tip of the iceberg for attacks against NAS devices. However, we’ve started to see NAS vendors coming up with new enterprise-facing products, and that will increased complexity as well as provide more potential attack surfaces. Usually the device will be expected to work out-of-the-box and be assumed safe, which is the key assumption that allows them to be so vulnerable to attacks.
