Spørgsmål:
Hvad skal jeg gøre, når jeg finder en mulig sikkerhedssårbarhed af offentlig interesse?
Jacob
2016-06-30 03:24:45 UTC
view on stackexchange narkive permalink

Lad os sige, at jeg fandt en mulig sårbarhed i et sikkerhedssystem. Systemet har været universelt betragtet som sundt i årevis og bruges i dag i hele verden.

Jeg er ikke ekspert i sikkerhed, men der er ting, der bekymrer mig:

  • Brug af et sikkerhedssystem, der tror, ​​at det er sikkert, er værre end ikke at bruge et, da jeg stole helt på dets sikkerhed af en eller anden grund;
  • Systemet er implementeret i forskellige lande, og afslørende detaljer om, hvorfor det ikke er sikkert, kan kompromittere dem, der ikke opdaterer deres systemer med det samme;
  • Jeg vil gerne tage æren for mit arbejde / opdagelse, men på samme tid kan opdagelsen være for stor for mig;
  • Der er i øjeblikket ikke noget reelt alternativ til dette sikkerhedssystem, da det er blevet overvejet det bedste i årevis, og ingen brugte tid og ressourcer på at finde en bedre;
  • At afsløre problemer uden at bringe en løsning virker som at sige til det videnskabelige samfund "Hej, alt hvad du betragtede som sikkert er ikke, skynd dig og find en bedre løsning ".

Af alle ovenstående grunde undrer jeg mig over, hvad nogen skal gøre i en så klodset situation.

Tilgiv min vaguen ss, men jeg tror, ​​du forstår årsagen.

Et bug-bounty-program som [Zero Day Initiative] (http://www.zerodayinitiative.com/) håndterer ansvarligt afsløring og betaler dig undervejs
Du burde ikke være ansvarlig for at levere en løsning.Det er almindeligt, at sikkerhedsforskere ikke leverer rettelser.Ansvarlig afsløring af sårbarheden vil være mere end nok
Væddemål er, hvad du tænker, er en sikkerhedsfejl faktisk ikke.Enten fordi du har forkert ræsonnementet, eller simpelthen fordi denne trussel faktisk ikke er "reel".Når du designer et sikkerhedssystem, tager du hensyn til dets formål, og hvilken slags trusler det skal håndtere.Det kan godt være, at den, du fandt, blev overvejet i designfasen og ikke betragtes som væsentlig for systemet (f.eks. Fordi udnyttelse af det ikke er trivielt og kræver en hel masse arbejde, som at have fysisk adgang og enorm computerkraft ved hånden osv..)
For eksempel: for nogen tid siden var der et par artikler om "sikkerhedsfejl" i KeePass.disse "mangler" var simpelthen: en nøglelogger og logget hovedadgangskoden.Men hele pointen med KeePass er * ikke * at beskytte brugeren mod en inficeret lokal maskine i første omgang.
Vent, jeg ved hvad det er.Du taler om den fælles dødboltlås, og du har opdaget bump-nøgler.
Enig med @Bakuriu;der er mange, mange tilfælde, hvor folk tror, at de har fundet en fejl, som ikke er en.Hvis du [google for "det snarere involverede at være på den anden side"] (https://www.google.com/webhp?q=%22it+rather+involved+being+on+++++side%22+site: blogs.msdn.microsoft.com) får du nogle gode eksempler fra Raymond Chen.
Jeg tvivler ganske meget på, at der virkelig ikke er ”noget reelt alternativ til dette sikkerhedssystem”.Når et system (f.eks. En webside) ikke kan repareres (og ikke bare kan fjerne det), tilføjer du sikkerhedsforanstaltninger et lag nedenfor: http-autorisation, filtrer de tilladte IP'er i firewall, kræver adgang via en VPN ... Ikke perfekt, menfungerer generelt som en løsning.
Fire svar:
André Borie
2016-06-30 04:10:42 UTC
view on stackexchange narkive permalink

Det ville være et spørgsmål om mening om, hvordan du skal gå videre. Vi har allerede et spørgsmål, der forklarer forskellige etiske måder at rapportere en sårbarhed på.

Først og fremmest, for noget så stort vil jeg personligt anbefale, at du forbliver anonym i starten, mens du forlader en måde at senere bevise, at det faktisk var dig, der opdagede sårbarheden. Opret en helt ny PGP-nøgle (ikke bundet til din identitet), underskriv dine meddelelser med den, og offentliggør dem anonymt (f.eks. Via Tor). Hvis du senere føler dig sikker på, at alt er i orden, og der ikke er hundreder af blodtørstige advokater, der kommer efter dig, kan du bruge den nøgle til at underskrive en besked, der siger, at det var dig (med dit fulde navn).

Jeg anbefaler den ansvarlige oplysningsmetode: du kommer i kontakt med udviklerne af nævnte sikkerhedssystem og giver dem lidt tid til at implementere en patch.

Hvis du ikke får noget svar, et dumt svar eller selv horder af vrede advokater, der gøder på dig, skal du bare bruge din anonymitet til at blive offentligt og lade alle vide, hvordan det firma håndterer sikkerhedsmangler.

Jeg er uenig i det faktum, at det at afsløre en fejl, mens det ikke giver et alternativ, er en dårlig idé. Den fejl kan måske allerede være kendt af de onde, og det er bedre, at alle ved om det (og i det mindste kan vide, at det ikke er sikkert) snarere end at lade de onde helt nyde at bruge disse oplysninger. Også selvom der ikke er noget alternativ nu, kan denne opdagelse motivere nogen til rent faktisk at lave et sikkert alternativ.

Endelig, mens jeg ikke ved, hvilken slags "sikkerhedssystem" vi taler om, sikkerhed skal gøres i lag, og ethvert selskab, der er afhængig af dette system, da dets eneste forsvar fortjener at gå ned, ligesom dem, der ikke gider at opdatere, når en løsning bliver tilgængelig.

"sikkerhed skal ske i lag, og ethvert selskab, der er afhængig af det system, da dets eneste forsvar fortjener at gå ned" - fanden, skal vi rulle vores egen TLS (i det mindste for adgangskoder) komplet med engangssalte til det tilfælde, at HTTPSskal findes sårbare over for aflytning?
@JanDvorak: Jeg tror Andrés pointe er ikke at udvikle nye sikkerhedsmekanismer, men at bruge ** mere end en ** af de allerede bevist.
@hamena314 ok, men skal jeg downloade et Javascript-kryptobibliotek, så jeg kan hash de adgangskoder, jeg sender via HTTPS?
@JanDvorak Jeg tror, at det ikke er tilfældet, men du skal sikre din ansøgning mod XSS (for eksempel).Du kan også gøre andre ting som hastighedsbegrænsning og anmodning-throtlling (stavet forkert).
@JanDvorak: Da kryptobiblioteket ville blive belastet over HTTPS, ville det ikke give yderligere sikkerhed.
user41341
2016-06-30 03:59:36 UTC
view on stackexchange narkive permalink

Du vil gerne kontrollere, at dette er en faktisk sårbarhed, typisk ved at oprette et Proof-of-Concept. Derfra kan du:

  • Kontakt sælgeren af ​​softwaren privat, forklare dine fund og de problemer, der er forbundet med den, vedhæfte poC'en, som de kan analysere.
  • Frigør sårbarheden for offentligheden i håb om, at den ekstra opmærksomhed vil overtale sælgeren til at frigive en rettelse.
  • Vær helt tavs om det og håb, at blackhats ikke finder det.

Den første mulighed er sandsynligvis den bedste. Du behøver ikke at afsløre din personlige identitet for at frigive oplysninger. Jeg har brugt flere håndtag og smid-konti til sådan kommunikation under lignende omstændigheder.

Den anden mulighed er risikabel. Du risikerer offentlig tilbageslag ("Hvorfor giver de en åben sårbarhed for de mennesker, der misbruger det?"), Og du sætter dig selv og sælgeren på et dårligt sted. Mens nogle mennesker bifalder din indsats, vil andre se dette som et problem.

Den tredje mulighed er endnu mere risikabel. Hvis du har mulighed for at oprette en PoC, så gør det også folk med ondsindet hensigt. Den eneste forskel her er din afprøvede og sande Sikkerhed gennem uklarhed aka en virkelig dårlig tid .

Din bedste chance er at starte med den første mulighed, falde tilbage til den anden, hvis du bliver fuldstændig ignoreret. Jeg har set historier om mennesker, der kontakter leverandører i flere måneder, endelig frigiver sårbarheden for offentligheden og derefter ser en programrettelse, der løser problemet. I en ideel verden vil sælgeren tage dette alvorligt og løse problemet, når du først har kontaktet dem. Medmindre de forsømmer problemet eller finder ud af, at det ikke er et spørgsmål, vil de være de bedste til at løse det. Hvis de ikke adresserer det, løber de den reelle risiko for at blive den næste Java eller Flash alias fuldstændig upålidelig for offentligheden.

Det er typisk dårligt for erhvervslivet.

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

Vil du tage kredit, men du vil ikke blive kendt? Det fungerer bare ikke.
Beslut hvad der er vigtigere: Kredit, eller gør sårbarheden kendt anonym.

Hvis det er vigtigere at gøre det kendt, ser jeg, at du har en ny konto osv., det er godt. (hvis det virkelig er så stort, håber jeg, du har et nyt operativsystem på en ny enhed, ingen browserprofil og Tor også. Hvis ikke, starter det nu for sent.).
Hvis du ikke engang er næste trin sikker på, at hvis det er en vuln, er det bare en start at fortælle os, at situationen her.

Om "ikke at fortælle, fordi det kan udnyttes": Nå, hvis du er bekymret for det, og din identitet, ser jeg ingen måde at fortælle det nogen. I dette tilfælde ... bare glem det?

Tjek mit svar, der er en måde at forblive anonym, mens du har mulighed for at bevise, at det var du, hvis du vælger at gøre det.
@AndréBorie Nå, men dette inkluderer stadig at opgive anonymitet ...
Med min løsning afhænger det af, hvordan du beskytter den private nøgle.Hvis du ikke får den stjålet og ikke genbruger nøglen, forbliver din anonymitet i orden.
@AndréBorie Min pointe er, at hvis han virkelig aldrig vil opgive anonymitet, har han ikke brug for det ...
@deviantfan Forståelsen er, at OP ønsker at opgive anonymitet senere, hvis tingene går godt, og forblive anonyme, hvis tingene ikke gør det.
@AndréBorie Vælg lidt tekst med dit navn i (som "Jeg er John Smith, johnsmith7@example.com. Den 01/07/2016 afslørede jeg Toothbooger-sårbarheden. 45tiy3wiucghcfq2roxq3wtv546fuo623" (og brug faktisk tilfældig tekst i stedet for tastaturmashing).Gem denne tekst et eller andet sted meget sikkert, tag den derefter, og tag derefter hasjen med i afsløringen.Hvis du senere ønsker at blive nonymøs (?), Skal du frigive teksten og den anvendte hashingalgoritme.
symcbean
2016-06-30 04:11:35 UTC
view on stackexchange narkive permalink

Blåfisken udeladte at nævne "Ansvarlig afsløring", hvor en betroet tredjepart leverer en spærretjeneste i en begrænset periode, hvilket giver sælgeren mulighed for at rette fejlen, samtidig med at opdageren krediteres. CERT sponsorerer en sådan tilgang.

Men i henhold til det forrige svar har du brug for et bevis på konceptet. Desværre introducerer "sikkerhedsprodukter" ofte sårbarheder, end de fleste professionelle forventer.



Denne spørgsmål og svar blev automatisk oversat fra det engelske sprog.Det originale indhold er tilgængeligt på stackexchange, som vi takker for den cc by-sa 3.0-licens, den distribueres under.
Loading...