Angribere, der blev til formål at udnytte brugere gennem sessionskidnapning på GitLab - den moderne webbaseret Git repository leder er blevet stoppet i deres spor som firma løser fejlen.
Kapring Bug og potentielle skader for GitLab og brugere
”Hvis der var en succesfuld udnytte på vegne af angriberen, sårbarhed i systemet kunne have indledt en omfattende liste over skadelige aktiviteter,” sagde Daniel Svartman der opdagede fejlen tilbage i maj i år. Men, Han kunne ikke give de oplysninger, indtil denne uge efter GitLab lappet fejlen og beroliget deres brugere spørgsmålet blev faste.
Hvis en hacker var en succes i deres forsøg på at brute-force en konto, de ville give sig selv mulighed for at styre den konto, dumpe koden, udføre opdateringer til regnskabet samt bemærkelsesværdigt potentiale for at stjæle dine personlige oplysninger og følsomme data i den holder af nye versioner af software, der er uudgivet til det offentlige. Der er andre muligheder hvorved udførelsen opdateringer til koden kunne gøre det muligt for hackeren at indlejre enhver malware ind i det.
Şvarţman havde bemærket noget ikke var helt ret, når han opdaget at hans session token var i hans webadresse. Således, alt, hvad han skulle gøre, var at kopiere og indsætte token flere gange og rundt på hjemmesiden for at sikre adgang til GitLab instrumentbræt, Kontooplysninger, andre individuelle og løbende virksomhedens projekter og endda webstedets kode.
Dette var ikke den eneste bekymrende faktor, der antydede noget var op med webstedet. Have session tokens eksponeret så åbent, at være synlig i URL'en, er om nok, mere så levende udsætte bug selv. Men, Det var Şvarţman anden opdagelse, at bekræftede hans indledende bemærkning: GitLab lab gør brug af vedvarende private sessions poletter, der ikke udløber. Hvad dette betyder, at hvis en hacker var i stand til at sikre adgang til en brugers session token, det ville ikke udløbe. Dette er specielt gavnligt for en angriber som sådan teknik kunne lade dem iscenesætte et angreb uger eller måneder efter, at de har stjålet oplysningerne, forlader offeret uvidende og clueless af indtrængen.
En anden mistænkelig funktion, spiked Şvarţman interesse var, at tokens var kun 20 tegn, forlader modtagelige for brute-tvinger. I betragtning af de token vedholdende natur og adgangen admin niveau givet til brugere, var der ingen tvivl om, at dette var en truende sikkerhedshul.
GitLab Rettelser Kapring Bug
Det vides endnu ikke, hvor længe sårbarheden havde forblev udsat for brugere, før det endelig blev fast. Men, forskeren påpeger, at han ikke var den første person til at fremhæve og bringe spørgsmålet op til GitLab have set brugere diskuterer det samme emne på selskabets supportfora.
Sikkerhed Bly på GitLab, Brian Neel, fremhævet, at virksomhedens brug af private tokens er ikke det vigtigste spørgsmål her og det er heller ikke et problem i sig selv. Han fortsatte med at uddybe:
”Dette er ikke noget, der kan udnyttes direkte. Eksistensen af private tokens bliver kun et problem, når det kombineres med et cross-site scripting eller anden sårbarhed. Generelt sagt, en konto hos en privat token er ved ikke mere risiko for kompromis, end hvis de tokens ikke eksisterede, medmindre en anden svaghed er gearet at stjæle token. De fleste moderne web services understøtter idéen om en privat token: AWS har adgang / hemmelige nøgler, GitHub har adgang tokens, Digital Ocean har tokens, etc. Den eneste reelle forskel mellem deres brikker og vores private tokens er, at de er begrænset til API og typisk krypteret. Vi støtter begge disse muligheder med personlige adgang tokens. GitLab øjeblikket udfase private poletter til fordel for personlig adgang tokens.”
GitLab, på den anden side, er også begyndt at erstatte private poletter med brugerdefinerede RSS tokens til at hente RSS-feeds. Dette initiativ er blevet sat på plads for at sikre, at ingen sessions-id'er bliver lækket. Personlig adgang tokens bliver også i stigende grad ansat i GitLab der ville tilbyde rollebaserede adgangskontrol, dermed øge sikkerhedsforanstaltninger samt.
