La vulnerabilità che ho indicato era in profondità al sistema operativo usato da Synology e non era evitabile tramite
alcun tipo di firewall
Direttamente da SecurityFocus:
"**************************************************************
Title: Synology DSM multiple vulnerabilities
Version affected: <= 4.3-3776
Vendor: Synology
Discovered by: Andrea Fabrizi
Email: andrea.fabrizi (at) gmail (dot) com [email concealed]
Web: Andrea Fabrizi
Twitter: @andreaf83
Status: unpatched
**************************************************************
Synology DiskStation Manager (DSM) it's a Linux based operating
system, used for the DiskStation and RackStation products.
1] ======== Remote file download ========
Any authenticated user, even with the lowest privilege, can download
any system file, included the /etc/shadow, samba password files and
files owned by the other DSM users, without any restriction.
The vulnerability is located in "/webman/wallpaper.cgi". The CGI takes
as parameter the full path of the image to download, encoded in ASCII
Hex format.
The problem is that any file type can be downloaded (not only images)
and the path validation is very poor. In fact the CGI checks only if
the path starts with an allowed directory (like
/usr/syno/synoman/webman), and this kind of protection can be easily
bypassed using the ../ attack.
For example to access the /etc/shadow:
2f7573722f73796e6f2f73796e6f6d616e2f7765626d616e2f2e2e2f2e2e2f2e2e2f2e2e
2f6574632f736861646f77
(/usr/syno/synoman/webman/../../../../etc/shadow)
------------------------------------------
GET /webman/wallpaper.cgi?path=AABBCCDDEEFF11223344 HTTP/1.1
Host: 127.0.0.1:5000
Cookie: stay_login=0; id=XXXXXXXXXXX
------------------------------------------
2] ======== Command injection ========
A command injection vulnerability, present on the
"/webman/modules/ControlPanel/ modules/externaldevices.cgi" CGI,
allows any administrative user to execute arbitrary commands on the
system, with root privileges.
------------------------------------------
POST /webman/modules/ControlPanel/modules/externaldevices.cgi HTTP/1.1
Host: 127.0.0.1:5000
User-Agent: ls
Cookie: stay_login=0; id=XXXXXXXXXXX
Content-Length: 128
action=apply&device_name=aa&printerid=1.1.1.1-aa';$HTTP_USER_AGENT>/tmp/
output+%23&printer_mode=netPrinter&eject_netprinter=true
------------------------------------------
Putting the command to execute as the User Agent string, after the
request the output will be ready into the /tmp/output file.
3] ======== Partial remote content download ========
For the localization DSM uses some CGI, that takes the lang parameter
(e.g. "enu" for english) and returns a Json object containing the
localized strings in a dictionary format.
The strings are taken from a local file with the following path:
[current_dir]/texts/[lang_parameter_value]/strings
The "/strings" appended at the end of the path prevents a path
injection, because any value injected using the "lang" parameter will
be invalidated (in other words, it's possible to read only files named
"strings"). But, the interesting thing is that the full path of the
strings files is built using a snprintf function like that:
snprintf(&s, 0x80u, "texts/%s/strings", lang)
This means that putting a lang value big enough, it's possible to
overflow the 128 byte allowed by the snprintf and take out the
"/strings" from the built path.
For example, the lang value
"./////////////////////////////////////////////////////////////////////
///////////////////../../../../../etc/synoinfo.conf" allow to get the
/etc/synoinfo.conf file content.
The second problem is that the input file taken by the CGI must be
formatted in a key/value way: key1=string1
In other words, to get some content from a generic file it's necessary
that the file contains at least an "=" for each line (this is the
reason why I called the vulnerability "Partial remote content
download").
At first glance it may seems very limiting, but, seen that it's
possible to read directly from the disk block device (e.g.
/dev/vg1000/lv), the amount of data dumped is very huge. In my tests I
was able to dump around the 25/30% of the drive (tested with mixed
content, like documents, images, generic files). It's possible to dump
data from any drive connected. Interesting data can be also dumped
from the /proc vfs.
This vulnerability impacts two different CGI and is exploitable
without authentication by any remote user:
/scripts/uistrings.cgi
/webfm/webUI/uistrings.cgi
------------------------------------------
GET /scripts/uistrings.cgi?lang=XXXXXXXXX HTTP/1.1
Host: 127.0.0.1:5000
------------------------------------------
In the system there are two other uistrings.cgi, but are not affected.
4] XSS
A classic Cross-site scripting affects the following CGI:
/webman/info.cgi?host=XXXX&target=XXXX&add=XXXX"
Certo, facendo riferimento ai pericoli del passato, a preoccuparsi devono essere solo una parte degli utenti Synology.
Detto questo però, considerato il livello e la qualità dello sviluppo del software della batteria di ingegneri di Synology,
facevo invece riferimento più che altro alle preoccupazioni di quanto possa (verosimilmente) continuare ad accadere
anche in futuro
Beh quello si, con qualsiasi sistema open anche se proprietario di un determinato produttore, quando finisce nelle mani dei comuni utenti cose del genere sono sempre dietro l'angolo. Il consiglio di aggiornare sempre all'ultima versione vale anche in questo casoLa vulnerabilità che ho indicato era in profondità al sistema operativo usato da Synology e non era evitabile tramite
alcun tipo di firewall:
"**************************************************************
Title: Synology DSM multiple vulnerabilities
Version affected: <= 4.3-3776
Vendor: Synology
Discovered by: Andrea Fabrizi
Email: andrea.fabrizi (at) gmail (dot) com [email concealed]
Web: Andrea Fabrizi
Twitter: @andreaf83
Status: unpatched
**************************************************************
Synology DiskStation Manager (DSM) it's a Linux based operating
system, used for the DiskStation and RackStation products.
1] ======== Remote file download ========
Any authenticated user, even with the lowest privilege, can download
any system file, included the /etc/shadow, samba password files and
files owned by the other DSM users, without any restriction.
The vulnerability is located in "/webman/wallpaper.cgi". The CGI takes
as parameter the full path of the image to download, encoded in ASCII
Hex format.
The problem is that any file type can be downloaded (not only images)
and the path validation is very poor. In fact the CGI checks only if
the path starts with an allowed directory (like
/usr/syno/synoman/webman), and this kind of protection can be easily
bypassed using the ../ attack.
For example to access the /etc/shadow:
2f7573722f73796e6f2f73796e6f6d616e2f7765626d616e2f2e2e2f2e2e2f2e2e2f2e2e
2f6574632f736861646f77
(/usr/syno/synoman/webman/../../../../etc/shadow)
------------------------------------------
GET /webman/wallpaper.cgi?path=AABBCCDDEEFF11223344 HTTP/1.1
Host: 127.0.0.1:5000
Cookie: stay_login=0; id=XXXXXXXXXXX
------------------------------------------
2] ======== Command injection ========
A command injection vulnerability, present on the
"/webman/modules/ControlPanel/ modules/externaldevices.cgi" CGI,
allows any administrative user to execute arbitrary commands on the
system, with root privileges.
------------------------------------------
POST /webman/modules/ControlPanel/modules/externaldevices.cgi HTTP/1.1
Host: 127.0.0.1:5000
User-Agent: ls
Cookie: stay_login=0; id=XXXXXXXXXXX
Content-Length: 128
action=apply&device_name=aa&printerid=1.1.1.1-aa';$HTTP_USER_AGENT>/tmp/
output+%23&printer_mode=netPrinter&eject_netprinter=true
------------------------------------------
Putting the command to execute as the User Agent string, after the
request the output will be ready into the /tmp/output file.
3] ======== Partial remote content download ========
For the localization DSM uses some CGI, that takes the lang parameter
(e.g. "enu" for english) and returns a Json object containing the
localized strings in a dictionary format.
The strings are taken from a local file with the following path:
[current_dir]/texts/[lang_parameter_value]/strings
The "/strings" appended at the end of the path prevents a path
injection, because any value injected using the "lang" parameter will
be invalidated (in other words, it's possible to read only files named
"strings"). But, the interesting thing is that the full path of the
strings files is built using a snprintf function like that:
snprintf(&s, 0x80u, "texts/%s/strings", lang)
This means that putting a lang value big enough, it's possible to
overflow the 128 byte allowed by the snprintf and take out the
"/strings" from the built path.
For example, the lang value
"./////////////////////////////////////////////////////////////////////
///////////////////../../../../../etc/synoinfo.conf" allow to get the
/etc/synoinfo.conf file content.
The second problem is that the input file taken by the CGI must be
formatted in a key/value way: key1=string1
In other words, to get some content from a generic file it's necessary
that the file contains at least an "=" for each line (this is the
reason why I called the vulnerability "Partial remote content
download").
At first glance it may seems very limiting, but, seen that it's
possible to read directly from the disk block device (e.g.
/dev/vg1000/lv), the amount of data dumped is very huge. In my tests I
was able to dump around the 25/30% of the drive (tested with mixed
content, like documents, images, generic files). It's possible to dump
data from any drive connected. Interesting data can be also dumped
from the /proc vfs.
This vulnerability impacts two different CGI and is exploitable
without authentication by any remote user:
/scripts/uistrings.cgi
/webfm/webUI/uistrings.cgi
------------------------------------------
GET /scripts/uistrings.cgi?lang=XXXXXXXXX HTTP/1.1
Host: 127.0.0.1:5000
------------------------------------------
In the system there are two other uistrings.cgi, but are not affected.
4] XSS
A classic Cross-site scripting affects the following CGI:
/webman/info.cgi?host=XXXX&target=XXXX&add=XXXX"
Certo, facendo riferimento ai pericoli del passato, a preoccuparsi devono essere solo una parte degli utenti Synology.
Detto questo però, considerato il livello e la qualità dello sviluppo del software della batteria di ingegneri di Synology,
facevo invece riferimento più che altro alle preoccupazioni di quanto possa (verosimilmente) continuare ad accadere
anche in futuro
si vale anche in questo caso, tant'è che sempre nello stesso thread indicato in precedenza del giugno di quest'anno,
era già stato caldeggiato tramite la procedura adottata ufficialmente da Synology sul proprio sito web:
http://www.synology.com/en-global/co...ws/article/437
In merito alla discussione su Synology volevo cercare di capire meglio il senso dei vostri interventi.
Totocellux ha indicato che i programmatori di Synology si sono mossi tardi rispetto a delle vulnerabilità note da tempo. Hanno poi tappato le falle con gli aggiornamenti.
La necessità di tenere un sistema aggiornato all'ultima versione è (per me) sempre fuori discussione.
Ma permettetemi di chiedervi di chiarire meglio il senso di questi discorsi in questa sede.
Stiamo dicendo che il software di Synology è più sicuro di altri perchè ha una casa produttrice che ci sta dietro? Quindi sarebbe da preferire un progetto come XPEnology rispetto ad altri progetti open come FreeNAS e OMV?
Vuol dire che progetti come gli ultimi citati non sono così sensibili alle questioni di sicurezza e vengono aggiornati con meno frequenza?
Io ho sempre pensato il contrario...
Sulla bontà del software Synology ho visto poche discussioni: in molti, quando si sceglie un NAS commerciale, optano per quest'ultimo per la bontà del DSM, ma non è detto che gli sviluppatori di una ditta siano sempre attentissimi e pronti anche sul fronte della sicurezza.
Sto dicendo delle ovvietà, ma è per capire meglio i vostri interventi.
Grazie mille!
ripeto il concetto espresso nel mio primo intervento: bisogna prestare attenzione ai sistemi operativi su base
open modificati direttamente dai vari produttori di dispositivi per aggiungere delle funzionalità, in quanto
senza potercene rendere conto, una serie di rischi alla base di tali modifiche, sono sempre alla nostra porta.
Quindi il mio è un atteggiamento quantomeno scettico in merito alle attività del team di sviluppo Synology
che dopo aver creato il problema è anche intervenuto in ritardo, solo successivamente alla scoperta della
grave falla di sicurezza da parte di un ricercatore indipendente.
Già in precedenza una serie di utenti avevano mostrato sul forum ufficiale dei dubbi e chiesto spiegazioni in
merito a traffico sospetto individuato dalla continua (ed immotivata) accensione dei led di stato del traffico
dei loro NAS in assenza di attività proprie. Ma la causa è stata scovata solo esternamente al Team.
E' la stessa cosa per la maggior parte dei sistemi: di sistemi open (come OMV e FreeNAS) ne esistono molti e hanno una fetta di utenza minore = difficilmente gli hacker perdono tempo a scovare falle..sistemi più diffusi come DSM, sistemi di altri NAS, Windows, firmware di router di marche famose ecc.. sono usati da più utenti = gli attacchi da parte degli hacker aumentano ma hanno un team di supporto alle spalle a cui tocca mantenerlo sicuro rilasciando continui aggiornamenti. Synology fino ad'ora ha supportato ampiamente i suoi NAS e i relativi sistemi per quanto riguarda sicurezza e aggiornamenti.
Spero di essermi spiegato bene
Finalmente il mio microserver è attivo e funzionante!!!
Ho deciso per OMV che ho installato su un disco SSD da 40gb (costo circa di 30€ spedito) e attualmente ho un unico disco WD Red da 4Tb.
Mi sono impratichito con la configurazione facendo dei test su una macchina virtuale, poi ho settato la macchina reale.
Sono stato a lungo indeciso sul filesystem con cui formattare il disco dei dati, in particolare la scelta era fra EXT4 e XFS, ma alla fine ho optato per il rodato EXT4.
L'unica cosa su cui ancora molto incerto è il settaggio del risparmio energetico sui dischi fisici (Advanced Power Management) di cui ho capito poco.
C'è qualche esperto di Linux che potrebbe aiutarmi a capire?
Io avrei lasciato XFS ma effettivamente credo sia un problema marginale.
Per l'apm che problema c'è? Non ci ho mai perso molto tempo ma ci possiamo guardare...
Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.
Sulla scelta del filesystem ho letto diversi articoli e visto diversi benchmark, ma molti sono relativi a situazioni che non riguarderebbero il mio uso (vedi l'interazione con database, ecc.).
Ho letto di utenti che consgliavano XFS in particolare per file molto grandi (salvo poi trovare un articolo in cui dice espressamente che con file molto grandi va in crisi) ma non ho trovato indicazioni o bench per un insime di file variegato, cioè con dimensioni molto variabili: io ho diverse foto da 2M l'una, diversi video da 350M, musica in flac con files dai 30M in su e qualche file mkv da 8 o 9 Gb...
Alla fine nella grande indecisione ho scelto EXT4 perchè più diffuso e anche perchè da quello che ho visto le differenze nelle prestazioni non sono poi così eclatanti.
Ma dico questo: se mi dai una buona ragione per passare a XFS, formatto adesso finchè il disco è ancora quasi vuoto!
Riguardo al Power Management.
Per ogni disco OMV propone i seguenti parametri da settare (credo siano settaggi comuni in Linux):
Capisco poco le differenze fra i vari valori del primo gruppo e anche a cosa serve il valore "Spindown Time".Advanced Power Management
-- Disabled
-- 1 – Minimum power usage with standby (spindown)
-- 64 – Intermediate power usage with standby
-- 127 – Intermediate power usage with standby
-- 128 – Minimum power usage with out standby (no spindown)
-- 192 – Intermediate power usage with out standby
-- 254 – Maximum performance, maximum power usage
Automatic Acoustic Management
-- Minimum performance, Minimum acoustic output
-- Maximum performance, Maximum acoustic output
Spindown Time
-- 0 to 360 minutes
Write Cache
-- Enable write-cache. (This function is effective only if the hard drive supports it.)
Inoltre non capisco questi valori come influiscono sui dischi normali e sugli SSD.
Ovviamente vorrei una configurazione che propende verso il risparmio energetico e sulla silenziosità (penso a tutte le ore nella giornata in cui il NAS rimarrà acceso senza essere utilizzato), sia per risparmiare corrente sia per preservare l'hardware il più possibile.
E' ovvio che non vorrei poi soffrire troppo sul fronte delle prestazioni.
Al momento ho optato per i seguenti settaggi sul WD (ma senza capirne a fondo il significato):
Sul disco SSD credo che certi valori non abbiano valenza. Ho settato:Advanced Power Management
-- 127 – Intermediate power usage with standby
Automatic Acoustic Management
-- Minimum performance, Minimum acoustic output
Spindown Time
-- 30 minutes
Write Cache
-- Enabled
Ogni suggerimento e chiarimento è davvero gradito!Advanced Power Management
-- 64 – Intermediate power usage with standby
Automatic Acoustic Management
-- Disabled
Spindown Time
-- Disabled
Write Cache
-- Enabled
Ci sono attualmente 2 utenti che stanno visualizzando questa discussione. (0 utenti e 2 ospiti)
|
nexthardware.com - © 2002-2022 |
Rispondi quotando