Sårbarhetspolicy
Ugreen Group Limited (nedan kallat "Vi" eller "Ugreen"), som tillverkare av NAS-produkter, lägger stor vikt vid säkerheten för sina egna produkter och verksamheter och inser vikten av integritet och datasäkerhet. Hanteringen av varje säkerhetsbrist och förbättringen av företagssäkerheten kan inte separeras från det gemensamma samarbetet mellan alla parter. Om du upptäcker eller tror att du har upptäckt en potentiell säkerhetsbrist i din användning av NAS-tjänster, uppmuntrar vi dig att rapportera din upptäckt till oss så snart som möjligt i enlighet med denna policy för sårbarhetsrapportering. Vi lovar att vi har dedikerad personal för att följa upp, analysera och hantera de problem som rapporteras av varje anmälare, och kommer att svara i tid.
1. Process för återkoppling och bearbetning av sårbarheter
[Feedback om sårbarheter]
Om du tror att NAS-produkter har sårbarheter eller säkerhetsincidenter som behöver rapporteras, vänligen fyll i följande formulär för sårbarhetsrapportering.
[Process för hantering av sårbarheter]
Steg 1: Rapportören behöver lämna detaljerad information om sårbarheten.
Steg 2: Ugreen kontrollerar och verifierar den mottagna sårbarhetsinformationen och utvärderar den.
Steg 3: Åtgärda sårbarheten och verifiera reparationen av NAS-produkter.
Steg 4: Släpp ut en ny version av NAS-produkten för uppdateringar.
Steg 5: Svara reportern med bearbetningsresultaten.
Steg 6: Övervaka NAS-produktens stabilitet efter uppdateringen.
[Sårbarhetsgranskningsfas]
1. Rapporten bekräftas inom 1 arbetsdag efter mottagandet och en första bedömning genomförs.
2. Inom 3 arbetsdagar kommer bedömningen att vara slutförd och sårbarheten åtgärdas eller en åtgärdsplan utarbetas.
[Buggfix] & Färdigställandefas]
1. Kritiska sårbarheter kommer att åtgärdas inom 3 arbetsdagar efter att bedömningen är slutförd.
2. Högrisksårbarheter kommer att åtgärdas inom 7 arbetsdagar efter att bedömningen är slutförd.
3. Sårbarheter med medelhög risk kommer att åtgärdas inom 30 arbetsdagar efter att bedömningen är slutförd.
4. Lågrisksårbarheter kommer att åtgärdas inom 60 arbetsdagar efter att bedömningen har slutförts.
5. Vissa sårbarheter är föremål för miljö- eller hårdvarubegränsningar, och den slutliga reparationstiden kommer att baseras på den faktiska situationen.
Ett separat säkerhetsmeddelande för nödsituationer utfärdas för allvarliga eller betydande sårbarheter.
2. Standarder för sårbarhetsklassificering
Beroende på graden av skada hos sårbarheter delas de in i fyra nivåer: allvarlig, hög risk, medelhög risk och låg risk risk.When När vi får en sårbarhetsrapport vidtar vi en rad åtgärder för att åtgärda den internt, internt med hänvisning till ISO/IEC 30111. Alla rapporterade sårbarheter poängsätts enligt Common Vulnerability Scoring System CVSS 3.1-kriterierna.
[Kritiska sårbarheter]
1. Sårbarheter för direkt fjärråtkomst till systembehörigheter (serverbehörigheter, klientbehörigheter, smarta enheter), inklusive men inte begränsat till godtycklig kodkörning, godtycklig kommandokörning, uppladdning och användning.
2. Kärnsystemet har logiska designfel, inklusive men inte begränsat till ändringar av kontolösenord utan några skyddsrestriktioner, all kontoinloggning etc.
3. Det leder direkt till allvarliga sårbarheter för informationsläckage i online-affärssystemet, inklusive men inte begränsat till SQL-injektionssårbarheter i kärndatabasen.
4. Mobil terminal: Sårbarhet med fjärrkodkörning som direkt kan påverka ett stort antal användare utan interaktion.
5. Enhetssidan: Fjärråtkomst till enhetskörningsbehörigheter (t.ex. nedladdning av annan NAS-användardata, fjärråtkomst till enheter etc.) i internetmiljön, det finns ingen sårbarhet för interaktiv fjärrkörning av kommandon i internetmiljön.
【 Högrisksårbarhet 】
1. Sårbarheter som direkt leder till läckage av känslig information på onlineservrar, inklusive men inte begränsat till läckage av källkod i kärnsystemet, nedladdning av serverkänsliga loggfiler etc.
2. Kärnverksamhetssystemet kan använda andras identitet för att utföra alla sårbarheter, vilket gör att kärnverksamhetssystemet kan vara viktig eller känslig för obehöriga operationer.
3. Obehörig åtkomst till hanteringsplattformen och användning av administratörsfunktioner, inklusive men inte begränsat till känslig bakgrundsinloggning för administratörskonton, aktiviteten på den relevanta plattformen, användarbas, funktionell betydelse och känslighet för användarinformation, kommer att betraktas som kriterier för hög risk för sårbarhetsbedömning.
4. Sårbarhet för informationsläckage med hög risk. Inklusive men inte begränsat till läckage av känsliga data som kan utnyttjas direkt, och läckagesårbarheter som kan leda till en stor mängd användaridentitetsinformation.
5. SSRF-sårbarheter med ekon som kan komma åt Ugreens intranät.
6. Mobil terminal: Tredjepartsapplikationer använder mobila klientfunktioner i olika applikationer för att utföra högriskåtgärder (som att läsa och skriva filer, läsa och skriva SMS och läsa och skriva klientdata) och högriskläckage av känslig information.
7. Enhet: erhåller körtillstånd för enheten (t.ex. nedladdning av annan NAS-användardata eller fjärråtkomst till enheter) från den nära källan eller nätverket. Det finns ingen sårbarhet för körning av interaktiva fjärrkommandon i den nära källan eller nätverket.
8. Enhet: Sårbarheter som på distans orsakar permanent överbelastningsattacker på enheter, inklusive men inte begränsat till fjärrattacker mot systemenheter (enheter kan inte längre användas, är helt permanent skadade eller hela systemet måste skrivas om), och attacker tillåter inte fysisk kontakt med enheter, och attacker måste snabbt replikeras i omgångar.
【Medelhög risksårbarhet】
1. Vanligt informationsläckage, inklusive men inte begränsat till lösenord för lagring i klartext för mobilklienter, som innehåller känslig information från servern eller databasen, källkod för nedladdning av komprimeringspaket.
2. De logiska designfel som finns i systemet, såsom kryphål i betalningssystem.
3. Sårbarheter orsakade av defekter i svaga autentiseringsmekanismer, inklusive men inte begränsat till känsliga funktioner där captcha kan brute force-knäckas, inloggningsgränssnitt utan captcha, etc.
4. SSRF-sårbarhet utan eko.
5. Sårbarheter som kräver interaktion för att erhålla användaridentitetsinformation, inklusive men inte begränsat till CSRF för känsliga operationer, lagrings-XSS, JSONP-kapning för känslig information etc.
6. Sårbarhet för fjärrstyrd överbelastning som kan inaktivera vissa funktioner i en onlineapplikation (måste visas för att påverka andra användare).
7. En sårbarhet som gör att en smart enhet nekar service. Till exempel utsätts en systemenhet för en lokalt initierad permanent denial-of-service-attack (enheten kan inte längre användas: helt permanent skadad eller hela operativsystemet måste skrivas om), en tillfällig denial-of-service-sårbarhet orsakad av fjärrattacker (fjärravstängning eller omstart), och attacken måste kunna replikeras snabbt i batchar.
8. En sårbarhet som gör att vanliga affärssystem kan använda andra personers identiteter för att utföra alla funktionella operationer utanför deras befogenhet.
【Låg risksårbarhet】
1. Sårbarheter som kan utnyttjas i nätfiskeattacker, inklusive men inte begränsat till sårbarheter i URL-omdirigering.
2. Lågriskiga logiska designfel.
3. Mindre sårbarheter för informationsläckage, inklusive men inte begränsat till sökvägsläckor, .git-filläckor och innehåll i affärsloggar på serversidan.
4. Sårbarheter som kan utnyttjas för nätfiske eller hackning, inklusive men inte begränsat till godtyckliga URL-justeringar och reflektiva XSS-sårbarheter.
5. Mobil terminal: lokal överbelastning (inklusive men inte begränsat till överbelastning orsakad av behörigheter för Android-komponenter som inte kommer från tredje part), mindre informationsläckage (som endast påverkar enskilda användare) etc.
6. En sårbarhet som gör att en enhet tillfälligt nekar service. Detta inkluderar men är inte begränsat till tillfälliga denial-of-service-attacker orsakade av lokala attacker (enheter måste återställas till fabriksinställningarna).
【Att ignorera problemet】
1. Buggproblem som inte är relaterade till säkerhet, inklusive men inte begränsat till långsam öppning av webbsidor, rörig stil etc.
2. Den inlämnade rapporten är för enkel och kan inte reproduceras enligt rapportens innehåll, inklusive men inte begränsat till de sårbarheter som inte kan reproduceras ens efter upprepad kommunikation med sårbarhetsrevisorn.
3. Outnyttjade eller ofarliga rapporter, inklusive men inte begränsat till falska CSRF (ingen egentlig påverkan på användare), lokala överbelastningsanrop som inte kan påverka andra, Self-XSS, PDF XSS, läckage av icke-känslig information (intranät-IP, domännamn), e-postbomber etc.
4. Ingen praktisk läckage av källkod.
5.Säkerhetsproblemet i den icke-Ugreen-modulen i hårdvaruprodukten, eller defekten i själva hårdvaran.
6. Säkerhetsproblem som Ugreen proaktivt avslöjar eller har avslöjats externt.
7. Säkerhetsproblem på produkter, appar eller webbapplikationer som inte längre underhålls.
8. Sårbarheter som Ugreen kan självvalidera internt är kända och har åtgärdats.
9. Överbelastning orsakad av behörigheter för tre Android-komponenter.
All information som lämnas till Ugreen om sårbarheter i NAS-produkter, inklusive all information i produktsårbarhetsrapporter, som du överför, kommer att ägas och användas av Ugreen.
Ugreen förbehåller sig rätten att ändra denna policy när som helst.