Fråga:
What to do when I find a possible security vulnerability of public interest?
Jacob
2016-06-30 03:24:45 UTC
view on stackexchange narkive permalink

Låt oss säga att jag hittade en möjlig sårbarhet i ett säkerhetssystem. Systemet har ansetts allmänt sundt i flera år och används idag över hela världen.

Jag är inte expert på säkerhet, men det finns saker som oroar mig:

  • Att använda ett säkerhetssystem som tror att det är säkert är värre än att inte använda ett, eftersom jag lita helt på dess säkerhet av vilken anledning som helst.
  • Systemet implementeras i olika länder, därför kan avslöja detaljer om varför det inte är säkert kompromissa med dem som inte uppdaterar sina system direkt;
  • Jag vill ta kredit för mitt arbete / upptäckt, men samtidigt kan upptäckten vara för stor för mig.
  • Det finns för närvarande inget riktigt alternativ till detta säkerhetssystem eftersom det har beaktats det bästa i flera år och ingen använde tid och resurser på att hitta en bättre;
  • Att avslöja problem utan att ta med en lösning verkar som att säga till det vetenskapliga samfundet "Hej, allt du ansåg vara säkert är inte, skynda dig och hitta en bättre lösning ".

Av alla anledningar ovan undrar jag vad ska någon göra i en sådan klumpig situation.

Förlåt min vaguen ss, men jag tror att du förstår orsaken.

Ett bug-bounty-program som [Zero Day Initiative] (http://www.zerodayinitiative.com/) hanterar ansvarsfullt avslöjande och betalar dig på vägen
Du borde inte vara ansvarig för att tillhandahålla en fix.Det är vanligt att säkerhetsforskare inte tillhandahåller korrigeringar.Ansvarsfullt avslöja sårbarheten kommer att vara mer än tillräckligt
Spel är vad du tänker är en säkerhetsfel egentligen inte.Antingen för att du har fel i resonemanget eller helt enkelt för att det hotet inte är "riktigt".När du utformar ett säkerhetssystem tar du hänsyn till dess syfte och vilken typ av hot den ska hantera.Det kan mycket väl vara att den du hittade ansågs under designfasen och inte ansågs vara betydelsefull för systemet (t.ex. för att utnyttja det inte är trivialt och kräver mycket arbete, som att ha fysisk tillgång och enorm datorkraft till hands etc..)
Till exempel: för en tid sedan fanns det några artiklar om "säkerhetsfel" i KeePass.dessa "brister" var helt enkelt: en keylogger och logga huvudlösenordet.Men hela poängen med KeePass är * inte * att skydda användaren från en infekterad lokal maskin i första hand.
Vänta, jag vet vad det här är.Du pratar om det vanliga dödbultlåset och du har upptäckt bump-nycklar.
Håller med @Bakuriu;det finns många, många fall där människor tror att de har hittat en brist som inte är en.Om du [google för "det handlade snarare om att vara på andra sidan"] (https://www.google.com/webhp?q=%22it+rather+involved+being+on++++++%22+site: blogs.msdn.microsoft.com) får du några bra exempel från Raymond Chen.
Jag tvivlar ganska mycket på att det verkligen inte finns "något verkligt alternativ till detta säkerhetssystem".När ett system (t.ex. en webbsida) inte kan repareras (och inte bara kan ta bort det) lägger du till säkerhetsåtgärder ett lager nedan: http-auktorisering, filtrera de tillåtna IP-adresserna i brandväggen, kräver åtkomst via en VPN ...fungerar i allmänhet som en lösning.
Fyra svar:
André Borie
2016-06-30 04:10:42 UTC
view on stackexchange narkive permalink

Det skulle vara en åsiktsfråga om hur du ska gå vidare. Vi har redan en fråga som förklarar olika etiska sätt att rapportera en sårbarhet.

För det första, för något så stort skulle jag personligen rekommendera att du förblir anonym först och lämnar ett sätt att senare bevisa att det verkligen var du som upptäckte sårbarheten. Skapa en helt ny PGP-nyckel (inte knuten till din identitet), underteckna dina meddelanden med den och publicera dem anonymt (via Tor till exempel). Om du senare känner dig säker på att allt är bra och det inte finns hundratals blodtörstiga advokater som kommer efter dig, kan du använda den nyckeln för att skriva ett meddelande om att det var du (med ditt fullständiga namn).

Jag rekommenderar ansvarsfull information: du kommer i kontakt med utvecklarna av säkerhetssystemet och lämnar dem lite tid att distribuera en patch.

Om du inte får något svar, ett dumt svar eller till och med horder av arga advokater som skäller på dig, använd bara din anonymitet för att bli offentlig och låta alla veta hur företaget hanterar säkerhetsfel.

Jag håller inte med om att avslöja en brist utan att tillhandahålla ett alternativ är en dålig idé. Den bristen kan redan vara känd för skurkarna och det är bättre att alla vet om det (och åtminstone kan veta att det inte är säkert) snarare än att låta skurkarna verkligen njuta av att använda den informationen. Även om det inte finns något alternativ nu kan denna upptäckt motivera någon att faktiskt göra ett säkert alternativ.

Slutligen, medan jag inte vet vilken typ av "säkerhetssystem" vi pratar om, säkerhet bör göras i lager och alla företag som förlitar sig på det systemet eftersom dess enda försvar förtjänar att gå ner, precis som de som inte bryr sig om att uppdatera när en fix blir tillgänglig.

"Säkerhet bör göras i lager och alla företag som förlitar sig på det systemet eftersom dess enda försvar förtjänar att gå ner" - jävla, ska vi rulla vår egen TLS (åtminstone för lösenord) komplett med engångssalter för fallet att HTTPSbör vara sårbara för avlyssning?
@JanDvorak: Jag tror att Andrés poäng inte är att utveckla nya säkerhetsmekanismer, utan att använda ** mer än en ** av de redan beprövade.
@hamena314 ok, men ska jag ladda ner ett Javascript-kryptobibliotek så att jag kan hash lösenorden som jag skickar via HTTPS?
@JanDvorak Jag tror att så inte är fallet, men du bör säkra din ansökan mot XSS (till exempel).Du kan också göra andra saker som hastighetsbegränsning och begäran-throtlling (felstavad).
@JanDvorak: Med tanke på att kryptobiblioteket skulle laddas över HTTPS skulle det inte ge ytterligare säkerhet.
user41341
2016-06-30 03:59:36 UTC
view on stackexchange narkive permalink

Du vill verifiera att detta är en faktisk sårbarhet, vanligtvis genom att skapa ett Proof-of-Concept. Därifrån kan du:

  • Kontakta leverantören av programvaran privat, förklara dina resultat och de problem som är förknippade med den, bifoga poC för dem att analysera.
  • Släpp sårbarheten för allmänheten i hopp om att den extra uppmärksamheten kommer att övertala säljaren att släppa en fix.
  • Var helt tyst om det och hoppas att blackhats inte hittar det.

Det första alternativet är förmodligen det bästa. Du behöver inte avslöja din personliga identitet för att släppa information. Jag har använt flera handtag och kasserade konton för sådan kommunikation under liknande omständigheter.

Det andra alternativet är riskabelt. Du riskerar allmän motreaktion ("Varför skulle de ge en öppen sårbarhet för de människor som skulle missbruka den?") Och du placerar dig själv och säljaren på en dålig plats. Medan vissa människor applåderar dina ansträngningar, kommer andra att se detta som ett problem.

Det tredje alternativet är ännu mer riskabelt. Om du har förmågan att skapa en poC, gör det också människorna med skadlig avsikt. Den enda skillnaden här är din beprövade Säkerhet genom obskärhet aka en riktigt dålig tid .

Din bästa insats är att börja med det första alternativet, falla tillbaka till det andra om du ignoreras helt. Jag har sett historier om människor som kontaktar säljare i flera månader, äntligen släppt sårbarheten för allmänheten och sedan sett en korrigeringsfil som behandlar problemet. I en idealisk värld tar leverantören detta på allvar och tar itu med problemet när du kontaktar dem. Om de inte försumar problemet eller finner att det inte är ett problem, kommer de att vara de bästa för att ta itu med det. Om de inte tar itu med det löper de den verkliga risken att bli nästa Java eller Flash aka helt otillförlitlig för allmänheten.

Det är vanligtvis dåligt för affärer.

deviantfan
2016-06-30 03:48:32 UTC
view on stackexchange narkive permalink

Vill du ta kredit men vill inte bli känd? Det fungerar bara inte.
Bestäm vad som är viktigare: Kredit eller att göra sårbarheten känd anonymt.

Om det är viktigare att göra det känt ser jag att du har ett nytt konto etc., det är bra. (om det verkligen är så stort hoppas jag att du har ett nytt operativsystem på en ny enhet, ingen webbläsarprofil och Tor också. Om inte, börja nu är för sent.).
Som nästa steg, om du inte ens är säker på om det är en vuln, bara berätta för oss situationen här är en början.

Om delen "att inte berätta för att kunna utnyttjas": Om du är orolig för det, och din identitet, ser jag inget sätt att berätta det för någon. I det här fallet ... glöm det bara?

Kolla in mitt svar, det finns ett sätt att vara anonym samtidigt som du har möjlighet att bevisa att det var du om du skulle välja att göra det.
@AndréBorie Tja, men detta inkluderar fortfarande att ge upp anonymitet ...
Med min lösning beror det på hur du skyddar den privata nyckeln.Om du inte får den stulen och inte återanvänder nyckeln förblir din anonymitet bra.
@AndréBorie Min poäng är att om han verkligen aldrig vill ge upp anonymitet behöver han inte det ...
@deviantfan Förståelsen är att OP vill ge upp anonymitet senare om det går bra, och förbli anonym om saker inte gör det.
@AndréBorie Välj lite text med ditt namn i det (som "Jag är John Smith, johnsmith7@example.com. 2016-01-01 avslöjade jag Toothboogers sårbarhet. 45tiy3wiucghcfq2roxq3wtv546fuo623" (och använd egentligen slumpmässig text) snarare än tangentbord.Spara den här texten någonstans väldigt säker, sedan hash den och ta sedan med hashen i avslöjandet.Om du senare vill bli nonymous (?) Släpper du texten och den hashingalgoritm som används.
symcbean
2016-06-30 04:11:35 UTC
view on stackexchange narkive permalink

Thebluefish utelämnade att nämna "Responsible Disclosure" där en betrodd tredje part tillhandahåller en spärrtjänst under en begränsad tid, vilket gör det möjligt för säljaren att åtgärda felet samtidigt som upptäckaren krediteras. CERT sponsrar ett sådant tillvägagångssätt.

Men enligt föregående svar behöver du ett bevis på konceptet. Tyvärr introducerar "säkerhetsprodukter" oftare sårbarheter än vad de flesta yrkespersoner förväntar sig.



Denna fråga och svar översattes automatiskt från det engelska språket.Det ursprungliga innehållet finns tillgängligt på stackexchange, vilket vi tackar för cc by-sa 3.0-licensen som det distribueras under.
Loading...