BACHELOROPPGAVE: Rammeverk for automatisk nettbasert rekognosering og informasjonsinnhenting FORFATTERE: Jan William Johnsen Kasper Kristoffersen DATO: 2014
Sammendrag av Bacheloroppgaven Tittel: Use thesistitle to insert your title here. Nr: Dato: 2014 Deltakere: Jan William Johnsen Kasper Kristoffersen Veiledere: Lasse Øverlier Oppdragsgiver: Kontaktperson: Stikkord Antall sider:?? Antall vedlegg: Tilgjengelighet: Åpen Kort beskrivelse av bacheloroppgaven: i
Summary of Graduate Project Title: Rammeverk for automatisk nettbasert rekognosering og informasjonsinnhenting Nr: Date: 2014 Participants: Jan William Johnsen Kasper Kristoffersen Supervisor: Lasse Øverlier Employer: Contact person: Keywords Thesis, Latex, Template, IMT Pages:?? Appendixes: Availability: Open Short description of the main project: This is the short description of a masters thesis ii
Forord iii
Innhold iv
Figurer v
Tabeller vi
1 Introduksjon For å være konkurransedyktige, så må bedrifter være tilstede på Internett for å tiltrekke seg kunder og aksjonærer. Internett blir benyttet til alt fra publisering av nyheter om bedriften, kommunikasjon mellom ansatte og lagring av filer, til å selge produkter, ta betaling for produktene, bare for å nevne noe. På grunn av tilgjengeligheten som Internett kan gi, så benytter bedriftene seg av den for både intern og ekstern bruk. De kobler sine egne systemer opp mot Internett, som igjen gjør at disse systemene kan tilkobles fra allmennheten. Dette gjør bedriftene i stand til å effektivisere sine forretninger. De behøver ikke lagre den samme informasjonen på flere steder, eller behandle den samme informasjonen flere ganger. Denne store tilstedeværelsen på Internett er, fra et forretningsmessig perspektiv, svært lønnsom. Mens tilgjengelighetens åpenbare sider er positive, så finnes det også skjulte negative sider. Kommersielle og veldig generelle systemer blir ofte ikke tilpasset til bedriften. Selv om løsningene er lett tilgjengelige for de ansatte, så er de i tillegg tilgjengelige for ondsinnede aktører. Det gjør at de negative sidene først oppdages etter at det har vært et innbrudd i disse systemene. Bedriften vil få et større fotavtrykk av å legge flere av sine løsninger på Internett, og blir dermed en lavthengende frukt som er de første som blir angrepet av datakriminelle. Det meste av informasjonen om bedriften, legger de selv ut. Altfor ofte blir denne informasjonen lagt ut uten at de har en egen policy for hva som kan publiseres. Men det finnes også informasjon som indirekte blir lagret om bedriften og dens ansatte. Filer og bilder som blir publisert inneholder ofte metadata. Denne metadataen kan inneholde GPS-koordinater for hvor bildet ble tatt; tidspunkter for når det ble lagret, sist åpnet og sist endret; brukernavn og e-post adresser. Store søkemotorer vil deretter kunne indeksere denne informasjonen som blir lagt opp på Internett av bedriften eller dens ansatte. Informasjonen vil dermed bli åpent tilgjengelig for alle. Denne rapporten, og rammeverket vi har utviklet, er beregnet på de som ikke vil være den lavthengende frukten. Det er i hovedsak oppdragsgiver Watchcom Security Group AS 1 som ønsker å ta i bruk rammeverket når de utfører penetrasjonstester for sine kunder. En penetrasjonstest er (enkelt forklart) et autorisert angrep mot systemer for å finne sårbarheter, og potensielt få uautorisert tilgang til systemene. En rapport om hvilke funn som er blitt gjort blir levert til bedriften, som kan gjøre utbedringer for å rette feilene før datakriminelle får mulighet til å utnytte dem. 1.1 Formål Oppdragsgiver ønsker å få utviklet et rammeverk som samler sammen og kjører flere verktøy gjennom ett og samme grensesnitt. Hvert verktøy har sine styrker og svakheter, men samlet gir de en oversikt over store deler av bildet. Selve utviklingen av dette rammverket kan deles inn i to hovedmål: analysere verktøy vi vil benytte som moduler, og 1 http://watchcom.no 1
implementere disse i et automatisert rammeverk. Denne automatiseringen skal gjøre at oppdragsgiver slipper å hoppe mellom flere forskjellige verktøy, fjerne duplikat input og output, og ellers redusere den manuelle arbeidsmengden. 1.2 Tidligere arbeid Det finnes en mengde enkeltstående verktøy der ute, og det ville tatt evigheter å se i gjennom alle disse for å finne noe som dekker sikkerhetskonsulentens behov. De benytter seg ofte bare av en brøkdel av de verktøyene som er tilgjengelige. Informasjonsinnhenting er den fasen av en penetrasjonstest som er den viktigste for å produsere en grundig rapport. Port- og sårbarhetsskanning-fasen har lenge vært semi-automatisert med verktøy som Nmap, Nessus, og OpenVAS (en fork av Nessus), men sikkerhetskonsulentene har lenge måttet gjennomføre informasjonsinnhentingen manuelt. På grunn av at denne fasen stort sett har vært manuelt arbeid, så har den ved mange anledninger blitt forsømt på grunn av tidsbegrensninger. Det var først når Recon-ng 2 kom i slutten av 2012, at konsulentene ikke lenger kunne skylde på tidsbegrensningene for å gjennomføre et godt forarbeid. Figur 1: Grått felt er informasjonsinnhenting-fasen, og sort linje er overgangen til portskanningfasen. a) representerer kort tidsbruk på informasjonsinnhenting-fasen, mens b) representerer mye tid brukt. Figuren viser at mer tid er lik større angrepsflate. Recon-ng gjorde det mulig for konsulentene å gjøre et godt forarbeid før de fortsatte på noen av de neste fasene av penetrasjonstesten. Recon-ng er et semi-automatisk rammeverk for nettbasert rekognosering. Det vi legger i ordet semi-automatisk er at modulene kjører automatisk, men det er en sluttbruker som må aktivere hver modul. Rammeverket har i tillegg en mulighet for å kjøre sekvensielle kommandoer fra en fil som blir lastet inn i starten av programmet. Den første planen vi hadde var å bygge videre på Recon-ng, men det ble ikke lenger et valg etter en grundig vurdering av verktøyet. Reconng er et nyttig verktøy, men på grunn av sine begrensninger så har vi valgt å bygge et eget rammeverk fra bunnen av. Disse begrensningene er blant annet at det lagrer for lite informasjon, modulene må lastes manuelt, og det finnes ingen eksportmuligheter til XML. 2 https://bitbucket.org/lanmaster53/recon-ng/wiki/home 2
1.3 Vår bakgrunn og kompetanse Vi studerer bachelor i informasjonssikkerhet ved Høgskolen i Gjøvik, tredje og siste året. Vi har gode grunnleggende kunnskaper innen programmering med objekt-orienterte språk som C++ og PHP, samt språk som C og noe scripting i Bash og PowerShell. Andre fag som IMT2571 Datamodellering og databaser og IMT2282 Operativsystemer har lært oss MySQL og hvordan Linux fungerer. Faget IMT2243 Systemutvikling vil hjelpe oss mye i dette prosjektet, siden vi utvikler et eget rammeverk fra bunnen av. I dette prosjektet vil vi benytte oss av det vi har lært i fagene som er nevnt over. Men vi må også tilegne oss nye kunnskaper under dette prosjektet. Det vi må tilegne oss er hovedsakelig kunnskap om hvordan nettbasert rekognosering og informasjonsinnhenting blir gjennomført, og i tillegg arbeide med, planlegging og implementering av et større systemutviklingsprosjekt. 1.4 Oppgavebeskrivelse Oppgaven er levert av Watchcom Security Group AS, og omhandler utviklingen av et rammeverk for nettbasert rekognosering og informasjonsinnhenting. Oppdragsgiver har gitt få føringer for gjennomføringen av oppgaven. De eneste kravene er at vi kun skal benytte tekniske metoder for innhenting av informasjon; lage et verktøy som automatiserer prosessen for ekstern footprinting"; verktøyet skal utvikles for Linux operativsystemer; rapportere tekniske funn i en menneskelig lesbar rapport og også et maskinvennlig format som XML eller JSON. Hele oppgaveforslaget kan leses i vedlegg??. Oppgaveforslaget fortsetter med å liste opp en rekke verktøy, deriblant Nmap. Vi tolker det slik at det kan se ut som om vi går over våre egne rammer ved å benytte portog sårbarhetsskanning, men det vil uten tvil gi verdifull informasjon som legges til i sluttrapporten. Oppdragsgiver nevner at vi bør strebe etter å innhente elementer fra alle punktene under Footprinting i PTES 3. Vi har ellers mye frihet til å gjennomføre prosjektet slik vi vil. Det er to hovedmål for oppgaven. Det første hovedmålet er å analysere flere verktøy for så å avgjøre hvilke av de som er best egnet til å gi en grundig informasjonsinnhenting. Hvert enkelt verktøy er en liten bit av puslespillet, og flere verktøy vil gi det større bildet til slutt. Vi må fokusere på å fjerne duplikater, data som er irrelevant, eller data som ikke kan bli brukt videre. Neste hovedmål er å implementere utvalgte verktøy som moduler i et automatisert rammeverk som oppdragsgiver kan bruke under sine penetrasjonstester. For at oppdragsgiver kan benytte den innsamlede informasjonen enklere og raskere, ønsker vi at rammeverket også skal ha mulighet til å dele sine data med andre rammeverk, som f.eks. Metasploit. Rammeverket skal samle inn så mye relevant informasjon som mulig, både fra målets eget nettverk og fra andre åpne kilder på Internett. Vi benytter en inkrementell utviklingsmodell for rammeverket. Etter planen vil dette gi oss et rammeverk med en solid bunnstruktur, og det vil også være enkelt å legge til flere moduler ved senere behov. Vi ønsker at rammeverket skal ha åpen kildekode 4. På grunnlag av at rammeverket skal ha åpen kildekode og er modulbasert, håper vi at det blir videreutviklet av andre som vil forbedre programmvaren eller legge til nye moduler ved senere anledninger. Det kan også forbedres og utvides med flere moduler under en senere bacheloroppgave. Det er tiltenkt at én modul skal inneholde ett verktøy. I tillegg 3 http://pentest-standard.org/index.php/intelligence_gathering 4 http://no.wikipedia.org/wiki/åpen_kildekode 3
minsker det sannsynligheten for at rammeverket blir puttet i en skuff og glemt. Rammeverket vil bli utviklet i Python. Implementasjonen vil dermed gå raskt og vi vil få et Proof of Concept etter relativt kort tid. Python passer bra til databaseprogrammer og er godt egnet for eksport til XML-format. For å kontrollere at rammeverket henter inn den riktige informasjonen, så vil vi sammenligne resultatet vi får ved å kjøre modulen gjennom rammeverket med resultatet fra det enkeltstående verktøyet. 1.5 Problemstilling Beskrivelse av problemstilling. Det bør bli tatt fra, eller være en videreføring av,?? Oppgavebeskrivelse. 1.6 Prosjektmål 1.6.1 Effektmål Effekten av dette prosjektet vil være at Watchcom kan utføre raskere og bredere informasjonsinnhenting. Det vil være raskere på grunn av at rammeverket vil automatisere bruken av flere verktøy. Disse automatiserte verktøyene vil aggregere data seg imellom, og også fjerne duplikat data. Dette vil føre til at den totale datamengden reduseres. Rammeverket analyserer data som samles inn og prioriterer hvor den vil ligge i rapporten ut ifra viktighet. En kjørende tjeneste med kjente svakheter vil eksempelvis bli presenter tidligere i rapporten enn en oppdatert tjeneste uten kjente svakheter. Kort oppsummert så vil rammeverket fungere som en analysemotor for eksisterende verktøy. Rammeverket vil også sammenstille data slik at dette ikke trengs å gjøres manuelt. Dette vil effektivisere forarbeidet og kartleggingen av kunden som penetrasjonstesten skal utføres for. Vi vil også forsøke å få sluttbrukerene til å spare enda mer tid ved å overføre resultatene rammeverket finner til andre verktøy som blir benyttet i de neste fasene av penetrasjonstesten. Det er ikke sikkert at vi kan oppnå den bredden som vi håper på, men vi vil hvertfall legge grunnmuren og gjøre det mulig for andre å utvide rammeverket for å oppnå denne bredden. Det også gi de samme effektene til andre aktører som har interesse for å ta i bruk rammeverket. 1.6.2 Resultatmål Vi har valgt å utvikle rammeverket til Kali Linux 5, som er en Debian-basert Linux distribusjon. Den avgjørende grunnen for dette valget er at denne distribusjonen inneholder de fleste verktøyene vi vil kunne ønske å implementere. Det er også en stor fordel at Kali Linux brukes av oppdragsgiver fra før. Kali Linux har en hel rekke forhåndsinstallerte verktøy på standard lokasjoner, som gjør at det blir relativt enkelt å kjøre rammeverket på oppdaterte versjoner av distribusjonen. Rammeverket vil bli terminalbasert, det gjør det lettere å aktivere rammeverket fra andre maskiner. Det vil bruke en IP-adresse, en IP-range eller en URL som hovedparameter. Andre parametere vil bli avgjort når behovet oppstår i utviklingsfasen. Rammeverket vil bruke disse parameterne til å samle personell- og systemdata fra målet. Innsamlingen av personelldata er for å identifisere individer, telefonnummere, brukernavn (og om mulig passord), data fra sosiale nettverk og metadata fra filer. Innsamlingen av systemdata er for å identifisere aktive systemer, åpne porter og service-versjoner, operativsys- 5 http://kali.org 4
temer, domener, IP blokker, og opplisting av DNS-informasjon. For å samle inn denne informasjonen så vil rammeverket kjøre sine moduler sekvensielt. Sluttproduktet som blir generert av rammeverket vil være en menneskelig lesbar rapport, samt XML som er et maskinvennlig format. 1.6.3 Begrensning av omfang Dette prosjektet vil fokusere på informasjonsinnhentingsfasen av en penetrasjonstest, det vil si at faser som port- og sårbarhetsskanning og exploitation i teorien er utenfor våre rammer, selv om vi kanskje vil inkludere noen verktøy eller eksportmuligheter for disse fasene. Vi utelukker å skanne private IP-adresser, fordi vi ikke får gjennomført søk av offentlige kilder mot målet. Søking i offentlige kilder er essensielt for å gjennomføre external footprintingdelen av informasjonsinnhentingen. Prosjektet vil foregå fra januar til juni 2014, med noen spesielle datoer: innlevering av rapport 19. mai, og fremføring av prosjektet mellom den 3. og 5. juni. 5
2 Kravspesifikasjon Dette kapitlet inneholder en beskrivelse av de funksjonelle og operasjonelle kravene som er satt for oppgaven. Dette inkluderer systemets omgivelser, begrensninger og rammer. Formålet med denne spesifiseringen er å skape klarhet i hva som faktisk skal utvikles og hvordan vi skal gjøre dette. 2.1 Funksjonelle krav Vi skal levere et automatisert rammeverk som vi har valgt å kalle Reccoon. Idéen til navnet fikk vi etter å ha lekt med ordet rekognosering (eng: reconnaissance). Til slutt blandet vi det med vaskebjørn (eng: raccoon). Vaskebjørner er små frekke tyver som stjeler fra offentlige søppelkasser, og vi sammenligner det med rammeverket vårt som også stjeler offentlig informasjon om andre. Figur 2: Reccoon logo, laget av Jonas Kristoffersen. Rammeverket vil kun ha én type sluttbruker: den personen som utfører penetrasjonstesten. Dette er en person som stort sett har administratorrettigheter (ofte kalt root 1 i Linux miljøer). Kali Linux har bare èn bruker, som er denne root-brukeren, og vi kan trygt anta at det er denne brukeren som blir benyttet under penetrasjonstestene. Det betyr at brukerhåndteringen av programmet vil være minimal. I utgangspunktet ser vi på sluttbrukeren som en sikkerhetskonsulent. Sluttbrukeren vil få produsert en rapport fra rammeverket, og avgjør selv om rapporten skal deles med flere personer. Det er viktig at sluttbrukeren har god kunnskap om hvordan informasjonsinnhenting blir praktisert og gjennomført. Rammeverket vil ikke gi brukeren noen melding om hvordan han eventuelt burde gå frem videre for å få aksess til målnettverket. 1 http://no.wikipedia.org/wiki/superbruker 6
Fire-and-forget er et uttrykk som brukes om tredjegenerasjons missilguide-systemer. Det betyr ganske enkelt at et mål kan låses, missilet avfyres - og deretter kan operatøren gå over til andre oppgaver, eller neste mål. Tiden som må brukes på hver missil blir dermed minimal [?]. Vi ser for oss at Reccoon vil være som slike fire-and-forget-missiler. I oppgavebeskrivelsen står det spesifikt at rammeverket skal være automatisert. Dermed er det eneste sluttbrukeren trenger å legge inn i programmet en IP-adresse, IP-range, eller en URL. Deretter vil rammeverket håndtere innsamlingen av informasjonen helt på egenhånd uten mer interaksjon fra sluttbrukeren. Rammeverket vil underveis gi regelmessige tilbakemeldinger på hvor langt i prosessen det har kommet. Rammeverket vil deretter automatisk kjøre gjennom modulene sine, det er modulene som gjør selve informasjonsinnhentingen. Hver av disse modulene er bygget for å bruke kun ett verktøy om gangen. Modulene vil kjøres sekvensielt, fordi noen moduler benytter informasjon som er hentet inn fra foregående moduler. Informasjonen som blir hentet inn fra modulene vil bli lagret i en MySQL-database. Når systemet er ferdig med å kjøre gjennom sine moduler, så vil det genereres et PDF dokument med resultatene fra informasjonsinnhentingen. Dette dokumentet vil i et menneskelig lesbart format, og det vil i hovedsak bli lest av sikkerhetskonsulenter. Systemet skal i tillegg generere et XML-dokument med de samme resultatene. Sluttbrukeren vil hele veien bli informert om hvor langt systemet er kommet i utførelsen. Elementene som systemet skal innhente er beskrevet i vedlegg??. Det vil ikke følge med noen bruksanvisning for hvordan man bruker rammeverket eller hva det gjør. Det er derfor viktig at sikkerhetskonsulentene er godt kjent med hvordan man utfører informasjonsinnhenting. Rammeverket vil forsøke å finne informasjon som er listet opp i vedlegg??. 2.1.1 Bruksmønster Et bruktsmønster (eng: use case) er en enkel representasjon av en brukers interaksjon med systemet. Det skildrer de ulike typer av brukere av et system, og de ulike måter som de samhandler med systemet [?]. Selv om et automatisk system har veldig begrenset interaksjon med brukeren, så har vi likevel valgt å skille på to operasjoner Reccoon kan utføre; normal utførelse av Reccoon, og normal utførelse av Reccoon med eksport av resultater til Metasploit. Forskjellen mellom disse måtene med interaksjon mot systemet er at Kjør Reccoon, eksporter til Metasploit vil eksportere nyttige resultater til Metasploit for å gjøre det enklere å starte på den neste fasen i en penetrasjonstest. På grunn av den enkle stilen til systemet blir det et enkelt bruksmønsterdiagram. 7
Figur 3: Bruksmønsterdiagram 2.1.2 Høynivå bruksmønsterbeskrivelse Navn: Aktør: Mål: Beskrivelse: Resultat: Kjør Reccoon Sluttbruker Finne informasjon om målet. Dette inkluderer skanning av åpne porter og sårbarheter. En sluttbruker starter Reccoon med gyldige parametere. Deretter vil Reccoon fortsette med å samle inn informasjon og skanne målet. Det blir generert en leselig rapport i PDF og XML av resultatene. Tabell 1: Høynivå beskrivelse av Kjør Reccoon. Navn: Aktør: Mål: Beskrivelse Resultat: Kjør Reccoon, eksporter til Metasploit Sluttbruker Finne informasjon om målet. Dette inkluderer skanning av åpne porter og sårbarheter. Eksportere resultatene til Metasploit. En sluttbruker starter Reccoon med gyldige parametere, samt spesifiserer at resultatene skal importeres til Metasploit. Det blir generert en leslig rapport i PDF og XML av resultatene. Resultater som er kompatible med Metasploit blir importert dit. Tabell 2: Høynivå beskrivelse av Kjør Reccoon, eksporter til Metasploit. 8
2.1.3 Detaljert bruksmønsterbeskrivelse Navn: Aktør: Utløser: Beskrivelse: For-betingelser: Aktørhandling: 1. Skriver inn kommandoer for å starte Reccoon fra en terminal. Kjør Reccoon Sluttbruker Aktør angir et mål som parameter når Reccoon blir startet. En aktør starter Reccoon med gyldige parametere. Etter at Reccoon er ferdig med å kjøre alle sine moduler, så blir det generert en PDF og XML rapport. Reccoon må ha tilgang på både MySQL database og verktøyene. Normal hendelsesflyt Systemhandling: 2. Sjekker om omgivelsene (gyldige parametere, MySQL database, tilgjengelige verktøy) er riktig for å kunne fortsette eksekveringen. 3. Kjører sekvensielt gjennom sine moduler. 4. Resultater fra modul blir lagret i MySQL databasen. 5. Genererer PDF rapport og XML dokument. 6. Rammeverket avslutter. Alternativ hendelsesflyt Ugyldig parametere, ikke tilkoblet Internett, ikke tilkoblet MySQL database, fant ikke verktøy, etc. Aktørhandling: 1. Skriver inn kommandoer for å starte Reccoon fra en terminal. Systemhandling: Tabell 3: Detaljert beskrivelse av Kjør Reccoon. 2. Sjekker om omgivelsene er riktig for å kunne fortsette eksekveringen. 3. Feilmelding blir skrevet ut. 4. Rammeverket avslutter. 9
Navn: Aktør: Utløser: Beskrivelse: For-betingelser: Aktørhandling: 1. Skriver inn kommandoer for å starte Reccoon fra en terminal. Kjør Reccoon, eksporter til Metasploit Sluttbruker Aktør angir et mål som parameter når Reccoon blir startet. En aktør starter Reccoon med gyldige parametere. Etter at Reccoon er ferdig med å kjøre alle sine moduler, så blir det generert en PDF og XML rapport. Reccoon vil importere sine resultater inn til Metasploit databasen. Reccoon må ha tilgang på både MySQL database og verktøyene. Normal hendelsesflyt Systemhandling: 2. Sjekker om omgivelsene (gyldige parametere, MySQL database, tilgjengelige verktøy) er riktig for å kunne fortsette eksekveringen. 3. Kjører sekvensielt gjennom sine moduler. 4. Resultater fra modul blir lagret i MySQL databasen. 5. Genererer PDF rapport og XML dokument. 6. Importerer resultater inn i Metasploit databasen. 7. Rammeverket avslutter. Alternativ hendelsesflyt Ugyldig parametere, ikke tilkoblet Internett, ikke tilkoblet MySQL database, fant ikke verktøy, etc. Aktørhandling: 1. Skriver inn kommandoer for å starte Reccoon fra en terminal. Systemhandling: Tabell 4: Detaljert beskrivelse av Kjør Reccoon. 2. Sjekker om omgivelsene er riktig for å kunne fortsette eksekveringen. 3. Feilmelding blir skrevet ut. 4. Rammeverket avslutter. 2.2 Operasjonelle krav Ytelse I oppgaveforslaget, og ved senere møter med oppdragsgiver, er det ikke spesifisert at rammeverket skal ha noen responstid eller ytelseskrav. Det er likevel nevnt ved møter at rammeverket kan ikke generere for mye trafikk på en gang slik at det blir utestengt fra målnettverket eller andre tredjepart tjenester. Rammeverket skal ikke bruke mer enn X MB og MySQL databasen skal ikke bruke mer enn X MB lokal lagringskapasitet. Det er ingen god måte å kvantifisere tiden som blir brukt for å skanne et målnettverk. Det blir for mange variable som antall maskiner som skal bli skannet, nettverkskapasiteten, etc. 10
Brukervennlighet Det vi legger i ordet brukervennlighet er ikke det at rammeverket er interaktiv med en sluttbruker, men det at brukeren ikke vil trenge noen opplæring for å bruke Reccoon. Rammeverket vil gi gode tilbakemeldinger til sluttbrukeren hvis det har blitt tastet inn ugyldige kommandoer, feil verdier, ikke tilgjengelige ressurser, etc. For de fleste feil vil databasen bli tømt og rammeverket avsluttes. Reccoon vil inkludere en installasjonsfil som vil installere databasen og det den ellers vil trenge for å kjøre. I denne oppgaven vil vi ikke prioritere avinstalleringen av Reccoon, derfor blir den ikke like enkel som installeringen. Avinstalleringen av Reccoon vil ikke bli like enkel, fordi vi ikke vil prioritere det i denne oppgaven. Men rammeverket vil inkludere en avinstalleringsmanual som sluttbrukeren kan følge og manuelt fjerne det Reccoon har installert. Robusthet Rammeverket er utsatt for å få mange feilmeldinger, fordi det er avhengig av at den har flere tilgjengelige ressurser. Ressurser er fra databasen og til de enkelte verktøy som blir benyttet. Ved feil som at en eller flere ressurser ikke er tilgjengelige, så vil rammeverket bare fortsette med neste modul hvis det er mulig og oppsummere feil som har oppstått til brukeren. Portabilitet Det er ingen krav for at rammeverket skal fungere i andre operativsystemer enn Kali Linux, vi vil utvikle og støtte versjon 1.0.x. Rammeverket vil uansett fungere på andre Linux operativsystemer hvis den tilfredsstiller kravene om at: verktøy er installert på riktig plass og tilgjengelig fra kommandolinjen. Med andre ord så bør Kali Linux bli benyttet. Vi vil ikke prioritere å overføre rammeverket til flere operativsystemer. Rapporten vil bli generert i PDF og XML formater på den lokale maskinen. Denne rapporten kan igjen bli printet ut eller sendt til flere maskiner av sluttbrukeren. Jus og etikk Reccoon samler inn åpen og offentlig informasjon om et mål. Åpen og offentlig informasjon er data fra sosiale nettverk, egne nettsider, Google søkeresultater, for å nevne noen. Det som kommer i en gråsone i loven er når Reccoon skanner IP-adresser for å se etter åpne porter, prøver å identifisere operativsystem, og finne sårbarheter til tjenester som kjøres ved målet. Dette gjør at ondsinnede aktører har et stort potensial for å bruke Reccoon til kriminelle handlinger. Bruksområdet til Reccoon er å komme disse aktørene i forkjøpet, og få rettet på sårbarheter som finnes i bedriftens systemer. Ondsinnede hensikter, som å utnytte disse sårbarhetene til egen vinning, er noe vi tar avstand fra. 2.3 Konseptuelt klassediagram I et konseptuelt klassediagram skal man finne klassene og relasjonene mellom disse som danner en god modell av den virkelige verden. En klasse er en beskrivelse av en type objekter, og deres felles egenskaper. Klassene er presentert som lister med attributter. Den logiske forholdet mellom klassene er representert med streker, og tallene representerer relasjonenen. Relasjonen 1..1 (en til en) betyr at relasjonen er unik, mens 0..* (0 til mange) betyr at flere kan ha den samme relasjonen. 11
Figur 4: Konseptuelt klassediagram 12
Det konseptuelle klassediagrammet illustrerer det vi ser at det endelige rammeverket vil bestå av. Klassediagrammet er normalisert til en viss grad. Valget for å ikke normalisere alt til 3NF (tredje normalform 2 ) er at databasen skal bare lagre informasjon. Vi kunne f.eks. normalisert inn geo-lokasjoner og adresser i tillegg. Men databasen skal ikke holde på data over en lenger periode eller ha store tabeller, så det er greit at tabellene inneholder duplikater i kolonner. Klassediagrammet har to hovedtabeller Hosts og Persons. Hosts vil lagre systeminformasjon om målet, og Persons vil lagre personalldata, altså informasjon om målets ansatte. Databasen er tiltenkt å lagre alt det som kan finnes med verktøy, for å gjøre genereringen av rapporten enklere. 2 http://no.wikipedia.org/wiki/normalisering 13
3 Analyse av verktøy Hvordan vi har prioritert det vi analyserer. Beskrivelse av hvert enkelt verktøy som vi har analysert. 14
4 Design 4.1 Arkitekturvisning Hvordan rammeverket skal se ut og oppføre seg. 4.2 Logisk visning Illustrasjon av komponenter og informasjonsflyt mellom dem. Detaljert illustrasjon av databasen. 4.3 Implementasjonvisning Vi vet ikke hva vi skal ha her, eller om vi skal ta det med i den endelige rapporten. 15
5 Implementasjon 5.1 Valg av lisens Begrunnelse på hvorfor vi har valgt open source. 5.2 Utviklingsmiljø Beskrivelse og begrunnelse av operativsystemet, programmeringsspråk, og databasespråk. Eventuelt eksterne Python moduler vi benytter. 5.3 Prioritere mållisten Vi beskriver hvordan vi prioriterer mållisten som blir generert av rammeverket. 5.4 Rammeverket For tidlig til å si noe om hva som skal være her. Vi vet ikke om denne kommer med i den endelige rapporten. 16
6 Test og analyse 6.1 Testmetode Vi beskriver hvordan hvordan hver modul innhenter de riktige data. 6.2 Vektlagte målepunkter En sjekkliste med hva vi har sett etter i testene. 6.3 Analyse av ytelse Vi forsikrer oss om at rammeverket ikke blir stengt ute av nettverk og nettsider, og ikke bruker urimelig lang tid. 17
7 Konklusjon 7.1 Måloppnåelse Hvilke mål som vi ikke har hatt en løsning til, men der vi har funnet en løsning. 7.2 Kravspesifikasjon og resultater Beskriver det vi har fått til fra kravspesifikasjonen, og det vi ikke har greit. 7.3 Fremtidig utvikling Hvilke moduler vi ønsker at blir lagt til eller hva mer som kan være i rammeverket. Vi håper på at rammeverket blir videreutviklet fordi det er open source. 7.4 Evaluering av gruppearbeid Hvordan vi har fungert som en gruppe. Om vi har hatt noen problemer under prosjektet. 18
Bibliografi [1] Wikipedia. Skyt-og-glem. 20. mars 2013. web. 4. februar 2014. http://no. wikipedia.org/wiki/skyt-og-glem. [2] Wikipedia. Use Case Diagram. 29. januar 2014. web. 5. februar 2014. http://en. wikipedia.org/wiki/use_case_diagram. 19
Watchcom Security Group AS - B.Sc thesis proposal Oppdragsgiver: A Oppgaveforslag Watchcom Security Group AS Postboks 1861, Vika N-0124 Oslo! Kontaktperson: Bjørn Richard Watne bjorn.watne@watchcom.no 918 12 177! Morten Gjendemsjø morten.gjendemsjo@watchcom.no 480 23 131! Eivind Utnes eivind.utnes@watchcom.no 400 09 040! Security- and penetration testing - Information correlation and reporting framework! Information gathering boils down to using the Internet to collect as much information as possible to about the target. Regardless of whether the information gathering is being done with offensive or defensive goals in mind, the value of the intelligence depends on coverage, quality of the analysis and how it is made accessible. While information gathering usually employ both technical and non-technical methods, this project is solely concerned with the former.! Security professionals employ numerous well-known tools when footprinting networks. Tools like Nmap provide both port scanning and host identification, while other tools like dnsenum, fierce and dnsmap can be used to provide insight into the domain. Metagoofil and Nessus can be used to extract metadata and scan for vulnerabilities, respectively.! All of the aforementioned tools have their strengths as well as restrictions and limitations. The common denominator is that they each provide a piece of the puzzle. The proposed project is to create a tool that automates the process of external network footprinting, by combining the pieces into a more complete view of a network s exposure on the Internet. A large part of this project will be to analyze the different tools output, i.e. removing duplicate data and extracting the most valuable and interesting information from each tool. That is, an automated tool that employs widely used information gathering tools, aggregates and analyzes, and reports the result in an appropriate manner.! The aggregated data should be presented in a machine-friendly format, e.g. JSON or XML. In addition, the tool should also produce a report aimed at security professionals incorporating a high degree of technical information about the target
Watchcom Security Group AS - B.Sc thesis proposal network. The data should be presented in an appropriate format, e.g. HTML, PDF or similar. The students should strive to include data from each of the "Footprinting" approaches mentioned in PTES [1].! The following list provides examples of tools that the students may choose to incorporate in data gathering. Please note that this list is by no means complete, and students are encouraged to add or remove tools as they see fit.! nslookup dnsenum/fierce traceroute telnet (banner grabbing) Nessus / Arachni Nmap Nikto Metagoofil Search engines (google hacking) Vendor/Equpment specific tools, e.g. cisco ios analysis.! This project requires knowledge of Linux as well as programming skills.! [1] http://www.pentest-standard.org/index.php/intelligence_gathering!
B Elementer B.1 System elementer Report name Customer IP range Customer IP Customer URL Domain Name System Domain name Domain holder name Registrar handle Legal-c handle Tech-c handle Name server handle* Created (YYYY-MM-DD) Last updated YYYY-MM-DD) NORID handle Type Name ID type ID number Registrar handle Post address Post code Post area Country Phone number Email address Target list (Prioritert rekkefølge) Host* IP address Country 22
Country code Region City Latitude Longitude ISP Port* Port ID (Number) Port protocol (tcp/udp) State (Open/Closed/Filtered) Service name Version Vulnerabilities* Common Vulnerability Scoring System (CVSS) OpenVAS Network Vulnerability Test (NVT) CVE CVSS score ID Name Family Vulnerability type Version Created Last modified Confidentialy impact Integrity impact Availability impact Access impact Authentication Gained access Summary CVSS base Risk factor CVSS base vector 23
Operating system Name Version Common Platform Enumeration (CPE) Vulnerabilities* B.2 Personell elementer Person list (Prioritert rekkefølge) Person* First name Last name Email address Position Username Password Password hash Hash type Telephone number Leaks (haveibeenpwned) 24