Are QNAP NAS’es trying to destroy all Synology NAS’es? Hang on let me explain, but before I do that a NAS is a Network Storage device, that typically today runs an embedded Linux OS, has a variety of applications and provides storage in the form of NFS, SMB and other protocols (even ISCSI) to devices on your network.
A weird thing has recently started happening.
My house which I expose many services has started getting attacked at a rate I haven’t seen before, digging deeper in to this they are coming from QNAP devices. QNAP devices attacking Synology NAS’es. Is this a coincidence? Are QNAP building their systems to take down their main competitor?
Let me explain a bit further.
In my house I expose a few services publicly (this website) and before you say, why aren’t you using a something like a Cloudflare Tunnel, there are some services I just can’t.
I don’t have too much compute at home, a few Raspberry Pi‘s (runs this website) but I also have a Synology NAS and I think it’s pretty awesome. It’s more than a bunch of fast storage. It’s an IPSEC VPN server, a IP Camera DVR (DSCAM), it streams content (DSVideo), it downloads content (DSGet), runs my MQTT broker (Container Manager via Docker) and keeps valuable data syncronished to the cloud (CloudSync), along with its core job of providing NFS and SMB storage.
In order to do this, most of the Synology services run off the same port via DSM (DiskStation Manager). I expose DSM at http://automation.baldacchino.net:81 and go ahead try and login, I am pretty aggressive. 1 failed login and you get banned for ever from not only DSM but all services (this website included).
So, what happened?
Before the last few weeks, I would get the odd email stating an IP has been blocked, but in the last few weeks I have blocked hundreds of IP’s.
Looking in to this more (because that’s me) I realised there is a pattern. And it’s not a patter based on the IP CIDR range or suffix.
Let’s take a look at two random IPs. 95.208.44.29/32 and 5.152.157.162/32
If I perform an IP Whois, we can extra some information, Germany and Italy. Nothing too special.
baldacchino_admin@Surface4-Baldacchino:~$ whois 95.208.44.29
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See https://apps.db.ripe.net/docs/HTML-Terms-And-Conditions
% Note: this output has been filtered.
% To receive output for a database update, use the "-B" flag.
% Information related to '95.208.0.0 - 95.208.127.255'
% Abuse contact for '95.208.0.0 - 95.208.127.255' is 'abuse.de@vodafone.com'
inetnum: 95.208.0.0 - 95.208.127.255
netname: KABELBW-07
descr: Vodafone BW GmbH
country: DE
admin-c: UMAC-RIPE
tech-c: UMTC-RIPE
status: ASSIGNED PA
mnt-by: KABELBW-MNT
mnt-by: UNITYMEDIA-MNT
mnt-by: KABELBW-MNT
created: 2009-01-30T17:07:31Z
last-modified: 2022-01-13T22:17:44Z
source: RIPE
role: Unitymedia Administration
address: Vodafone West GmbH
address: Ferdinand-Braun-Platz 1
address: 40549 Düsseldorf
address: GERMANY
admin-c: MH3982-RIPE
admin-c: HZ1532-RIPE
tech-c: UMTC-RIPE
nic-hdl: UMAC-RIPE
mnt-by: UNITYMEDIA-MNT
mnt-by: KabelBW-MNT
created: 2009-07-10T11:13:10Z
last-modified: 2023-01-12T14:56:28Z
source: RIPE # Filtered
role: Unitymedia Technical Contact
address: Vodafone West GmbH
address: Ferdinand-Braun-Platz 1
address: 40549 Düsseldorf
address: GERMANY
admin-c: UMAC-RIPE
admin-c: UMAB-RIPE
tech-c: MH3982-RIPE
tech-c: HZ1532-RIPE
nic-hdl: UMTC-RIPE
mnt-by: UNITYMEDIA-MNT
mnt-by: KabelBW-MNT
created: 2009-07-10T11:13:10Z
last-modified: 2023-01-12T14:57:31Z
source: RIPE # Filtered
% Information related to '95.208.0.0/17AS29562'
route: 95.208.0.0/17
descr: KabelBW
origin: AS29562
mnt-by: KabelBW-MNT
created: 2013-05-28T12:31:08Z
last-modified: 2013-05-28T12:31:08Z
source: RIPE
% Information related to '95.208.0.0/17AS3209'
route: 95.208.0.0/17
descr: Vodafone West
origin: AS3209
mnt-by: UNITYMEDIA-MNT
created: 2021-03-08T22:13:04Z
last-modified: 2021-03-08T22:13:04Z
source: RIPE
% This query was served by the RIPE Database Query Service version 1.109.1 (SHETLAND)
baldacchino_admin@Surface4-Baldacchino:~$ whois 5.152.157.162
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See https://apps.db.ripe.net/docs/HTML-Terms-And-Conditions
% Note: this output has been filtered.
% To receive output for a database update, use the "-B" flag.
% Information related to '5.152.156.0 - 5.152.157.255'
% Abuse contact for '5.152.156.0 - 5.152.157.255' is 'abuse@alconn.it'
inetnum: 5.152.156.0 - 5.152.157.255
netname: AY-MOBILENET-2
descr: alternatYva S.r.l.
country: IT
admin-c: aAO43-RIPE
tech-c: aN4795-RIPE
status: ASSIGNED PA
mnt-by: lir-it-alconn-1-MNT
created: 2020-11-24T08:31:07Z
last-modified: 2021-12-09T10:02:52Z
source: RIPE
role: alternatYva Administrative Office
address: viale luigi schiavonetti 286C
address: 00163 - Rome, Italy
admin-c: DM12103-RIPE
tech-c: aN4795-RIPE
nic-hdl: aAO43-RIPE
mnt-by: DM12103-MNT
created: 2012-07-10T15:51:33Z
last-modified: 2017-10-13T09:00:48Z
source: RIPE # Filtered
role: AlternatYva NOC
address: viale luigi schiavonetti 286/C
address: Rome
address: IT
tech-c: DM12103-RIPE
nic-hdl: aN4795-RIPE
mnt-by: DM12103-MNT
created: 2011-11-10T11:19:20Z
last-modified: 2017-10-13T08:58:32Z
source: RIPE # Filtered
abuse-mailbox: abuse@alternatyva.it
% Information related to '5.152.157.0/24AS60530'
route: 5.152.157.0/24
origin: AS60530
mnt-by: lir-it-alconn-1-MNT
created: 2021-12-09T17:18:40Z
last-modified: 2021-12-09T17:18:40Z
source: RIPE
% This query was served by the RIPE Database Query Service version 1.109.1 (SHETLAND)
But if we hit these IPs over HTTP and look at the HTTP headers did, we just find a pattern? We sure did.
baldacchino_admin@Surface4-Baldacchino:~$ curl --insecure -v https://95.208.44.29
* Trying 95.208.44.29:443...
* Connected to 95.208.44.29 (95.208.44.29) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=TW; ST=Taipei; L=Taipei; O=QNAP Systems, Inc.; OU=QTS; CN=QNAP NAS; emailAddress=support@qnap.com
* start date: Mar 11 10:45:27 2016 GMT
* expire date: Mar 9 10:45:27 2026 GMT
* issuer: C=TW; ST=Taipei; L=Taipei; O=QNAP Systems, Inc.; OU=QTS; CN=QNAP NAS; emailAddress=support@qnap.com
* SSL certificate verify result: self-signed certificate (18), continuing anyway.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* Using Stream ID: 1 (easy handle 0x563e3dd86e90)
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
> GET / HTTP/2
> Host: 95.208.44.29
> user-agent: curl/7.81.0
> accept: */*
>
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
< HTTP/2 200
< date: Wed, 07 Feb 2024 02:55:40 GMT
< server: http server 1.0
< x-frame-options: SAMEORIGIN
< content-type: text/html; charset=UTF-8
< last-modified: Thu, 03 Mar 2022 07:20:54 GMT
< accept-ranges: bytes
< content-length: 580
< vary: Accept-Encoding
<
<html style="background:#007cef">
<head>
<meta http-equiv="expires" content="0">
<script type='text/javascript'>
pr=(document.location.protocol == 'https:') ? 'https' : 'http';
pt=(location.port == '') ? '' : ':' + location.port;
redirect_suffix = "/redirect.html?count="+Math.random();
if(location.hostname.indexOf(':') == -1)
{
location.href=pr+"://"+location.hostname+pt+redirect_suffix;
}
else //could be ipv6 addr
{
var url = "";
url=pr+"://["+ location.hostname.replace(/[\[\]]/g, '') +"]"+pt+redirect_suffix;
location.href = url;
}
</script>
</head>
<body>
</body>
</html>
* Connection #0 to host 95.208.44.29 left intact
baldacchino_admin@Surface4-Baldacchino:~$ curl --insecure -v https://5.152.157.162
* Trying 5.152.157.162:443...
* Connected to 5.152.157.162 (5.152.157.162) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=TW; ST=Taipei; L=Taipei; O=QNAP Systems, Inc.; OU=QTS; CN=QNAP NAS; emailAddress=support@qnap.com
* start date: Mar 11 10:45:27 2016 GMT
* expire date: Mar 9 10:45:27 2026 GMT
* issuer: C=TW; ST=Taipei; L=Taipei; O=QNAP Systems, Inc.; OU=QTS; CN=QNAP NAS; emailAddress=support@qnap.com
* SSL certificate verify result: self-signed certificate (18), continuing anyway.
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* Using Stream ID: 1 (easy handle 0x559bf36fce90)
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
> GET / HTTP/2
> Host: 5.152.157.162
> user-agent: curl/7.81.0
> accept: */*
>
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
< HTTP/2 200
< date: Wed, 07 Feb 2024 02:56:26 GMT
< server: http server 1.0
< x-frame-options: SAMEORIGIN
< content-type: text/html; charset=UTF-8
< last-modified: Wed, 14 Feb 2018 21:50:33 GMT
< accept-ranges: bytes
< content-length: 580
< vary: Accept-Encoding
<
<html style="background:#007cef">
<head>
<meta http-equiv="expires" content="0">
<script type='text/javascript'>
pr=(document.location.protocol == 'https:') ? 'https' : 'http';
pt=(location.port == '') ? '' : ':' + location.port;
redirect_suffix = "/redirect.html?count="+Math.random();
if(location.hostname.indexOf(':') == -1)
{
location.href=pr+"://"+location.hostname+pt+redirect_suffix;
}
else //could be ipv6 addr
{
var url = "";
url=pr+"://["+ location.hostname.replace(/[\[\]]/g, '') +"]"+pt+redirect_suffix;
location.href = url;
}
</script>
</head>
<body>
</body>
</html>
* Connection #0 to host 5.152.157.162 left intact
We sure did find a pattern, these are all QNAP NAS’es. Hitting with a browser it shows all QNAP’s with a Firmware < 5.0
So there is a pattern, these IP’s are an army of QNAP servers that have been trying to break in to my house.
And a quick search online confirmed my hunch.
- https://www.bleepingcomputer.com/news/security/over-29-000-qnap-devices-vulnerable-to-code-injection-attacks/
- https://www.hkcert.org/security-bulletin/qnap-nas-remote-code-execution-vulnerability_20230131
- https://www.tomshardware.com/news/hackers-exploit-qnap-vulnerabilities-turn-nas-crypto-miners
- https://www.cvedetails.com/vulnerability-list/vendor_id-10080/Qnap.html
So, what do you do?
If you are reading this and have system such as NAS’es, IP Cameras that are connected, more so via port address translation, stop and remember about the risks we all take. They are almost always today based on some form of x86/ARM compute running embedded Linux, with an OS and yes, they can be vulnerable. They are a computer that needs updating!
By not using a NAT tunnel or form of reverse proxy you need to ensure your systems are up to date and are patched (obvious right). Consider and ask yourself, do you really need to expose ‘said’ device, if you do, what are you doing to detect and mitigate malicious threat actors? It needs to be layered approach, don’t only rely on having a patched environment (a good start). I like to triangulate with data points. An example can you perform some form of MRTG via a SNMP trap to detect irregular usage or block all TCP access at your edge.
You need a mitigation plan. You need to understand your surface attack area and you need to own it.
Life is about choice; it is about understanding impact versus risk, and I hope this at the very least was somewhat comical and opens your eyes to the wild west that is the internet.
Oh, and to answer my question, are QNAP devices attacking Synology devices (well yes), but not on purpose 😉
Thanks
Shane Baldacchino
1 thought on “Battle of the NAS’es – Why are QNAP NAS’es attacking my Synology NAS?”