Symantec: ? Slå av pcAnywhere nå

[xibriz]

Problemet er nok at dere ikke ser mulighetene på samme måte som meg.

 

Problemet er at dine synspunkter ikke hører hjemme i denne diskusjonen.

 

Så i stedet for å fokusere på fulltilgang på koden ( da kan man lage en modifisert utgave som gjerne bryter de innebygde sikkerhetssperrene ) så spør jeg heller om i hvilken grad man har tilgang til den fullstendig koden ?

 

Det er denne modifisere utgaven jeg har vektlagt hittil

 

Hvis du har 100% av all koden, og lager din egen modifiserte kopi av denne har du følgende problemstillinger:

1. Hvis dette er en kode som må kjøre på en server, hvordan skal du da installere denne på serveren du vil angripe?

2. Hvis dette er en kode som må kjøre på en klient, hvordan skal du da installere denne på klienten du vil angripe?

 

Begge problemstillinger har følgende løsning: en eller annen form for Social Engineering

 

Løsningen er ikke ett sikkerhetshull eller ett tegn på usikker kode.

 

Selv om det kan ta tid så er det mulig lage programmer som forsøker å finne de originale innhogg dataene , når man vet hvordan konverteringen gjøres samt at man har de konverterte dataene.

 

programmet gjetter bare seg frem med prøve og feil metoden , helt til dataene er blitt identiske

 

Det du snakker her er brute force, og da trenger du ikke bare metoden de orginale innloggingsdataene er blitt kryptert med (denne har vi i dette tilfellet), men også de faktiske dataene som er kryptert.

 

Her er det koden som har lekket, ikke de krypterte dataene.

 

Men jeg skal gi deg ett lite poeng her, fordi siden man ikke har de krypterte dataene må man hele tiden kjøre sammenligningen mot det orginale systemet. Og dette kan i værste tilfelle ikke bli stoppet hvis man har usikker kode.

Endret 3. februar 2012 av xibriz

[sinnaelgen]

Spørsmålet var om fri programvare ( som gjerne legger ved kilde koden ) er mere usikker en lukket program vare:

 

Her har jeg grundig gitt mine synspunkter på hvorfor fri programvare der man får med eller kan laste ned kilde koden er en større sikkerhetsrisiko.

 

Det hele dreier seg om hvor mye av den originale koden man kan redigere /kopiere.

Endret 3. februar 2012 av den andre elgen

[Occi]

Vi forstår at du mener at åpen kildekode er mer usikkert, men det er altså ikke det. Å ha tilgang til kildekode er ikke det samme som å tilgang til programdata. Derfor er koden trygg om den er sikker, også i åpen form.

[Simen1]

Problemet er nok at dere ikke ser mulighetene på samme måte som meg.

Problemet er at du ser muligheter som ikke fins. Hvor lang tid tar det før du leser deg nok opp på temaet til at du skal skjønne at du tar feil? Hvor mange innlegg skal til før du innrømmer at du tar feil?

[Gjest Slettet-t8fn5F]

Spørsmålet var om fri programvare ( som gjerne legger ved kilde koden ) er mere usikker en lukket program vare:

Ehh nei. Diskusjonen er hva som kan gjøres med kildekoden man har til er utbredt program som pcanywhere.

Mange har sagt at man kan lete gjennom kildekoden for å utnytte bakdører, som gutta i symantec ikke vet om eller har funnet. Om man finner ei bakdør eller et sikkerhetshull, så må man lage en kode som utnytter dette hullet. Å lage denne koden er lettere, når man har tilgang på kildekoden og dermed lage seg et verktøy som gjør at man kan ta kontroll over en maskin, system, nettverk eller lignende.

Bakdører kan også være pålagt fra amerikanske myndigheter ala NSA slik at de har en tilgang på nevnte program. Disse programmerte bakdørene finnes ikke i åpen kode da de veldig fort blir oppdaget av de som kan og ikke av de som fildder hjemme og tror de kan.

[sinnaelgen]

Vi forstår at du mener at åpen kildekode er mer usikkert, men det er altså ikke det. Å ha tilgang til kildekode er ikke det samme som å tilgang til programdata. Derfor er koden trygg om den er sikker, også i åpen form.

 

Nå virker det som du ikke har fått med deg hele debatten .

Jeg har bl.a. forklart hvordan jeg mener at man kan få tilgang til også programdata når kildekoden er åpen .

 

 

Simen1: Det er nettopp det man ser ikke alle muligheten får noen har klart å bevise at de finnes .

Inntil da er mange av disse mulighetene utenkelige.

Mye av dette blir da rette opp i, i senere versjoner

[sinnaelgen]

Spørsmålet var om fri programvare ( som gjerne legger ved kilde koden ) er mere usikker en lukket program vare:

Ehh nei. Diskusjonen er hva som kan gjøres med kildekoden man har til er utbredt program som pcanywhere.

Mange har sagt at man kan lete gjennom kildekoden for å utnytte bakdører, som gutta i symantec ikke vet om eller har funnet. Om man finner ei bakdør eller et sikkerhetshull, så må man lage en kode som utnytter dette hullet. Å lage denne koden er lettere, når man har tilgang på kildekoden og dermed lage seg et verktøy som gjør at man kan ta kontroll over en maskin, system, nettverk eller lignende.

Bakdører kan også være pålagt fra amerikanske myndigheter ala NSA slik at de har en tilgang på nevnte program. Disse programmerte bakdørene finnes ikke i åpen kode da de veldig fort blir oppdaget av de som kan og ikke av de som fildder hjemme og tror de kan.

 

Det var det opprinnelige spørsmålet , det jeg tok opp kom lit senere

[Occi]

Vi forstår at du mener at åpen kildekode er mer usikkert, men det er altså ikke det. Å ha tilgang til kildekode er ikke det samme som å tilgang til programdata. Derfor er koden trygg om den er sikker, også i åpen form.

Nå virker det som du ikke har fått med deg hele debatten .

Jeg har bl.a. forklart hvordan jeg mener at man kan få tilgang til også programdata når kildekoden er åpen .

Programdata blir generert utifra data som et program behandler, dette kan da f. eks være at Ola Nordmann registrerer seg på diskusjon.no, og i denne prosessen skriver han blant annet inn et passord. Dette blir dermed tolket av serveren til diskusjon.no som i dette tilfellet kjører php, hvor det passordet han har skrevet inn blir kryptert og resten av persondataen til Ola blir lagret i en database som f. eks MySQL.

 

At du veit hvilken algoritme som er blitt brukt for krypteringen, koden for input og koden for selve behandlingen av dataen som Ola har sendt inn, så betyr ikke det at du har tilgang til dataen da dette kjører som en isolert prosess og selv om du som ekstern veit hva som skjer, så kan du ikke påvirke dette.

 

Når da prosessen er ferdig, så ligger altså passordet lagret i kryptert form i en database, og det er ikke mulig å gå andre veien igjen og få passordet i klartekst om det er brukt en sikker krypteringsalgoritme. Eneste mulighet er å bruteforce, men om Ola har vært smart nok til å bruke et godt passord så kan du sette av X antall servere og du vil fortsatt ikke være i nærheten av å cracke passordet. Statistisk sett.

 

Det jeg prøver å si er at selv om du veit hvordan dataen behandles, så betyr ikke det at du klarer å hente ut denne som ekstern aktør. Mange av programmene som kjøres på servere som er ekstremt viktige at skal være sikre, er også open-source. Men Ola Nordmann kan føle seg trygg uansett, nettopp pga. programdesignet til mange av disse programmene. Du veit hva som foregår, men du kan ikke hente ut resultatet eller påvirke det (såfremt det ikke er bugs eller sikkerhetshull).

 

Jeg ønsker deg velkommen til å faktisk skissere en tenkt situasjon hvor du kan ha nytte av å kjenne kildekoden til et sikkert system (dvs. du vil ikke kunne finne noen sikkerhetshull i koden).

[007CD]

Programdata blir generert utifra data som et program behandler, dette kan da f. eks være at Ola Nordmann registrerer seg på diskusjon.no, og i denne prosessen skriver han blant annet inn et passord. Dette blir dermed tolket av serveren til diskusjon.no som i dette tilfellet kjører php, hvor det passordet han har skrevet inn blir kryptert og resten av persondataen til Ola blir lagret i en database som f. eks MySQL.

 

At du veit hvilken algoritme som er blitt brukt for krypteringen, koden for input og koden for selve behandlingen av dataen som Ola har sendt inn, så betyr ikke det at du har tilgang til dataen da dette kjører som en isolert prosess og selv om du som ekstern veit hva som skjer, så kan du ikke påvirke dette.

 

Når da prosessen er ferdig, så ligger altså passordet lagret i kryptert form i en database, og det er ikke mulig å gå andre veien igjen og få passordet i klartekst om det er brukt en sikker krypteringsalgoritme. Eneste mulighet er å bruteforce, men om Ola har vært smart nok til å bruke et godt passord så kan du sette av X antall servere og du vil fortsatt ikke være i nærheten av å cracke passordet. Statistisk sett.

 

Det jeg prøver å si er at selv om du veit hvordan dataen behandles, så betyr ikke det at du klarer å hente ut denne som ekstern aktør. Mange av programmene som kjøres på servere som er ekstremt viktige at skal være sikre, er også open-source. Men Ola Nordmann kan føle seg trygg uansett, nettopp pga. programdesignet til mange av disse programmene. Du veit hva som foregår, men du kan ikke hente ut resultatet eller påvirke det (såfremt det ikke er bugs eller sikkerhetshull).

 

Jeg ønsker deg velkommen til å faktisk skissere en tenkt situasjon hvor du kan ha nytte av å kjenne kildekoden til et sikkert system (dvs. du vil ikke kunne finne noen sikkerhetshull i koden).

 

Bare litt pirk Occi, du vil helst nevne passord krypteringen som hashing, siden kryptering kan bli toveis om det er en nøkkel for dekryptering og kryptering.

Elgen blander disse to så det kan være greit å lære han forskjellen på kryptering og hashing av ett passord.

 

Ellers har du ett svært bra eksempel.

Endret 4. februar 2012 av 007CD

[Occi]

Forsåvidt sant nok det, allikevel burde det ikke være stort rom for misforståelser om man faktisk veit hvordan f. eks md5, sha1 osv. fungerer. Gi input, få ut hash. Når du sier det så er jeg faktisk litt usikker på om det er rett å kalle det en kryptering i det hele tatt, eller om det kun kan betegnes som hash

[xibriz]

Hash er vel enveis, mens kryptering er toveis?

[LostOblivion]

Hash er vel enveis, mens kryptering er toveis?

 

Stemmer det. Med mindre det er en hashing-algoritme som produserer unike hashes, så kan forskjellige data hashes til samme hash. Det som imidlertid er vanlig, f.eks. når det gjelder passord, er å ikke 'dekryptere' passordet på disk, men å hashe passordet som brukeren taster inn. Da vil det hashes til samme passord, som matcher hashen som ligger på disk.

 

Det er feil å kalle hashing for kryptering.

Endret 4. februar 2012 av LostOblivion

[Matsemann]

Ettersom en hash funksjon også brukes enormt mye til annet enn å hashe passord, vil jeg si det er feil å omtale det som kryptering.

 

Nå sier man at passord ligger kryptert i dagligtale, men det har nok litt med at folk vet hva kryptering er og det er lettere enn å greie ut om hashing.

[LostOblivion]

Anonymous<3 LOL elsker de gutta...nå kan ACTA og all that shit tenke seg om to ganger!

 

'De gutta' er hvem som helst som synes det er kult å få creds...har du hacket noe, sender du en anonym mail og sier at 'Anonymous' gjorde det. Det er ikke en definert gruppe hackere, det kan være hvem som helst.

Endret 4. februar 2012 av LostOblivion

[sinnaelgen]

La os bruke omkoding ( i mangel på et bedre ord ) som felles betennelse i stedet. jeg er fullstendig klar over at det er fler måter å gjøre det på.

 

Poenget er at f.eks passordet som sammenlignes på serveren ikke er det samme i rette forstand som de man skrev inn siden det er omkodet.

 

Alt dett har jeg faktisk hatt i tanken når jeg mener at det er fult mulig å lure systemet når de forutsetningene jeg har lagt til grunne er oppfylt

 

Jeg er såpass overbevist at det må en solid beskrivelse hvordan man er sikret seg mot slikt før jeg klarer å godta det

 

 

 

Det jeg har snakket om hele tiden er at man kan lure systemet hvis disse forutsetningene er oppfylt :

- man kjernen alt av programkode som brukes ( det inkluderer hvordan serveren gjør det ) .

- man kan hente ut passordet o.l. i kodet form

 

Man trenger ikke en gang å kjøre serveren. Det holder at man simulerer den på en vanlig pc samme med klient delen

 

Når man da hr funnet passord alt det andre så er det bare å logge seg inn på vanlig måte

 

her må jeg bemerke at da er det snakk om alt av kode som kan avsløre sikkerhetsmetodene .

 

Hvis sikkerheten skal fungere så må det være noe som er skult , enten data eller programkode.

[Occi]

Du har åpenbart ikke lest og/eller ikke forstått innlegget mitt elgen. Men jeg får si det igjen:

 

Åpen kildekode betyr ikke at du har tilgang til programdata!

 

Dette innebærer altså at du ikke har tilgang til passordene i hashet/kryptert/"omkodet" fordi det er åpen kildekode. Hele prosessen kjører også vanligvis i isolert form, og du har derfor ingen mulighet til å vite 100% hvilken programdata som er generert av andre brukere via f. eks noe serverprogramvare.

 

Det du diskuterer er ikke det samme som den originale diskusjonen, men bare for å gjøre det klinkende klart så kan du godt få tak i passord i hashet form, men det kan fortsatt være at du ikke klarer å cracke de via bruteforcing.

Endret 4. februar 2012 av Occi

[Matsemann]

- man kan hente ut passordet o.l. i kodet form

Og det kan en ikke uten at det er en sikkerhetsbrist en plass.

 

Det du prater om innebærer at du allerede har fått hentet ut lagrede passord, og vil finne ut hva originalpassordene er for å kunne logge deg inn. Det er et reellt scenario, men langt unna det du skriver.

 

La oss si at jeg ønsker å lagre passordet mitt "1234". Det kjøres i en hash-funksjon, og blir lagret som "abfgbdtr". Du har funnet ut at passordet mitt i hashform er "abfgbdtr" og kan algoritmen som ble brukt, så da er det bare å prøve (bruteforce) til du treffer et passord som gir ut hashen "abfgbdtr" og du har passordet mitt.

 

Det finnes igjen sikkerhetstiltak mot dette. Det kalles salting. Så når jeg installerer et Open Source program der du kan se ALL kildekode, så når man konfigurerer det, så velger man det vi kaller "saltet". La oss si jeg velger "abc" som mitt salt.

Når jeg da skal lagre passordet mitt, "1234", plusser vi på saltet og hasher istedet "1234abc" og får hashen "llfas32t". Mitt hashede passord har du fått tak i, og kjører så bruteforce til du får ut "1234abc" som resultat. Mater du det inn i mitt program, er det derimot feil passord.

 

Dette gjøres så klart litt mere avansert enn det jeg skisserer her, men poenget er at _selv_ om du skulle sitte på hashede passord, er det ofte laget sikkerhetstiltak som tar høyde for det i gjen.

[sinnaelgen]

Da må du forklare meg en ting hvordan kan original programmet lese programdata og behandle det , men jeg lager et nytt programma basert på den samme programkoden så kan ikke programmet lese disse dataen til tross for at koden er identisk.

 

her kan man hvis man vill få programmet til vise originaldataene på skjermen.

[Matsemann]

Hvordan skal ditt program ha tilgang til data på en annen maskin?

[Occi]

Da må du forklare meg en ting hvordan kan original programmet lese programdata og behandle det , men jeg lager et nytt programma basert på den samme programkoden så kan ikke programmet lese disse dataen til tross for at koden er identisk.

 

her kan man hvis man vill få programmet til vise originaldataene på skjermen.

Som jeg sier; det er en isolert prosess/program, og kjører f. eks på en server. Du har jo selvsagt ikke tilgang til denne bare pga. det er åpen kildekode. Tusenvis av servere bruker programmer som stiller stort krav til sikkerhet, som samtidig er open-source. OpenSSH er et eksempel, om ikke så relevant så er det i alle fall mye brukt og sikkert.