Assembly: Hvordan utnytter man en buffer overflow

[Burnski]

Kan noen forklare meg dette? Hvordan bruker man en buffer overflow i hackersammenheng?

[MrLee]

30 minutter på å vente på forumsvar, som alike vel kom fra et 10 sekunders google søk?

 

http://en.wikipedia.org/wiki/Buffer_overflow

[LonelyMan]

Buffer overflow er uansett en dårlig måte å ta over et program på. Dette er noe jeg har drevet mye med. Sørg for å ha programmet i forhøyet modus og alltid sørg for at usikre programmer kjører i user mode, helst i en sandboks. Om du ikke bruker sandboks, kan du programmere din egen api hook, som overstyrer de nødvendige rutiner for at det kan skje. Og ha DEP aktivert (vær obs på at programmer kan slå av DEP programmatisk)

 

Der fins adskillig mer kompliserte metoder, de som jeg selv har utviklet er for kompleks til å gå i detaljer her, men jeg har metoder hvor jeg kan gjøre hva jeg vil med et program, om det er kryptert, om det er kodet med spagetti kode, om IAT tabellen er forkludret med, om API hooks er installert eller om det har anti debug metoder spiller ingen rolle, de metodene jeg har utviklet virker på alt som er der ute. De som føler at programmet sitt er veldig trygt bør tenke om igjen, det er ikke trygt.

Endret 10. mai 2012 av LonelyMan

[GeirGrusom]

Sørg for å ha programmet i forhøyet modus og alltid sørg for at usikre programmer kjører i user mode, helst i en sandboks

Kanskje du burde redigere innlegget ditt? Dette henger ikke helt på greip.

 

Til TS:

 

Buffer-overflow er ganske simpel, men ikke en veldig effektiv metode. Det fungerer på et bittelite fåtall av programmer i dag.

Idéen er ihvertfall at programmer skrevet i C ofte hadde statiske arrays som ble allokert i stack-området til programmet:

Eksempelvis:

int input_data[256];

 

Dersom man visste om dette, så hadde man en fast referanse til programmets oppførsel i forhold eksekveringsplan. Ved å fylle inn tomrommet kunne en dataforespørsel redigere programkoden.

Et praktisk eksempel på dette var at SQL Server (en eller annen versjon for en stund siden) hadde dette som et sikkerhetshull ved en forespørsel etter databaser. Da var dette et array definert mer eller mindre likt med det over, hvor angrepskode bare satt inn mellomrom (eller noe slikt) i forespørselen helt til arrayet ble fullt. SQL Server gjorde ingen test på dette, og fortsatte bare å fylle inn etter arrayet var helt fullt. Den ondsinnede koden fortsatte da å fylle inn helt til den kom til programområdet til SQL Server hvor den injiserte sin egen kode og funksjonalitet som gjorde at serveren startet å gjøre akkurat det samme fortløpende mot nye IP adresser.

[LonelyMan]

Sørg for å ha programmet i forhøyet modus og alltid sørg for at usikre programmer kjører i user mode, helst i en sandboks

Kanskje du burde redigere innlegget ditt? Dette henger ikke helt på greip.

 

Ja for deg høres det unormalt ut, det er nettopp fordi jeg vet hva jeg prater om. Og du må ikke forsøke å late som du vet mer enn meg for det gjør du ikke.

[GeirGrusom]

Ja for deg høres det unormalt ut, det er nettopp fordi jeg vet hva jeg prater om. Og du må ikke forsøke å late som du vet mer enn meg for det gjør du ikke.

Hvorfor påpeker du da at "usikre programmer" må kjøre i User mode? Du får det til å virke som om brukeren har noe valg på hvilken ring et program skal kjøre i.

 

Edit: jeg prøver meg ikke på noen forbanna pissekonkurranse her, men hvis du kan så mye om sikkerhet og du har skrevet løsninger som kan bryte seg inn i alle systemer så virker det merkelig å komme med de utsagna du gjorde over der.

Endret 10. mai 2012 av GeirGrusom

[LonelyMan]

så virker det merkelig å komme med de utsagna du gjorde over der.

 

Hva eksakt synes du er merkelig? Nå må du være konkret.

[GeirGrusom]

så virker det merkelig å komme med de utsagna du gjorde over der.

 

Hva eksakt synes du er merkelig? Nå må du være konkret.

Et User mode program er et program som kjører i prosessor ring 3. Dette er alle programmer i Windows med unntak av "Process". Motsetningen er Kernel mode som er ring 0 som Process kjører i, og drivere med unntak av user mode drivere fra Windows Vista og nyere.

 

At det er trygt å kjøre i sandbox er heller ingen selvfølge, og du må da enten kjøre i en virtuell maskin, eller et annet sandbox miljø. Ofte har ikke brukeren noe stort valg for dette, men jeg vil være enig at det er lurt å kjøre "utrygge" programmer i en virtuell maskin da det utgjør en vesentlig mindre risiko, men den er fortsatt ikke fraværende.

 

API-hook er heller ikke like relevant lenger, ettersom det kreves at programmer kjører i elevert eller som administrator for å hooke andre prosesser fra og med Windows Vista. En kan heller ikke skrive til andre prosessers minne lenger uten eleverte rettigheter. Du mente at brukere burde kjøre programmene i elevert modus til tross for at dette vil gjøre systemet mer usikkert da angrepskode får større frihet til for eksempel å gjøre hooking eller skrive til prosessminne.

 

Kanskje du kan være mer spesifikk med det du har gjort? Jeg er ihvertfall interessert i at du utdyper.

[LonelyMan]

Vel det viser seg at du ikke leste hva jeg skrev. Jeg sa at han burde kjøre det programmet han ønsket å ha beskyttet, i forhøyet modus, nettopp av årsaker du nå beskriver. Slik at ikke usikre programmer som kjører med lavere privilegier ikke kan gjøre disse tingene.

 

Vi tenkte likt her, men du misforstod meg. Så lenge et program kjører i forhøyet modus så kan ikke et usikkert program du ikke stoler på, gjøre så veldig mye med det som kjører forhøyet.

 

Du tenkte som så at jeg anbefalte han å kjøre usikre programmer i forhøyet modus, og det var feil. Han burde kjøre det programmet han stoler på (som han muligens har programmert selv) i forhøyet modus, og så kjøre usikre i lavere modus.

Endret 14. mai 2012 av LonelyMan