sådan hackes usikker internetapplikation

i denne artikel vil jeg gerne demonstrere, hvor let det er at få fortrolige oplysninger fra en internetapplikation, der… godt, betaler ikke for meget opmærksomhed på sikkerhed. Hvad jeg vil arbejde med er et eksempel på Java-program, som jeg oprettede i Spring Boot til demonstrationsformål. Men de udførte angreb er gyldige for ethvert andet programmeringssprog eller ramme. Nogle sårbarheder og sikkerhedsproblemer, der vil blive demonstreret, inkluderer:

• injektion
• følsom dataeksponering
• utilstrækkelig logning
• brudt godkendelse

opsætningen

vi vil arbejde med et fiktivt internetprogram, der giver dig mulighed for at logge ind som bruger, som er en del af en gruppe. Baseret på brugerrolle kan han se enten grundlæggende eller fortrolige data. I dette tilfælde vil du se en liste over medarbejdere i en virksomhed, deres status osv.

du kan finde kilderne til denne ansøgning i min Github: https://github.com/rapasoft/hackme.

angreb #1: Man in the middle attack

Forestil dig, at du sidder i en restaurant og gerne vil tjekke noget i applikationen ovenfor. Du opretter forbindelse til restaurantens trådløse internet, åbner login-siden, indtaster legitimationsoplysninger og får oplysninger, du ønsker (f.eks. listen over specifikke medarbejdere). Hvad du måske ikke nu, er, at dine legitimationsoplysninger er blevet kompromitteret. Lad os undersøge login-siden nøje:

denne applikation bruger ikke SSL/TLS (f.eks. Dette betyder, at alle sendte oplysninger kan ses som almindelig tekst af alle med adgang til kommunikation mellem klienten og serveren.

dette er præcis, hvad der sker i såkaldte Man in the middle angreb. Mere specifikt er ARP-spoofing i dette tilfælde blevet brugt som en måde at forgifte hele netværket på, så angriberen er opmærksom på alt, hvad der foregår og kan snuse på alle pakker. Jeg vil ikke gå nærmere ind på, hvordan ARP-spoofing fungerer, men vil demonstrere det på denne video:

du skal muligvis åbne denne Youtube-video i et nyt vindue og fuldskærm for at se flere detaljer

hvad du kan se ovenfor er, at jeg har startet Ettercap, som er en omfattende pakke til MITM-angreb, og udført ARP-spoofing i mit lokale netværk. I mellemtiden, når brugeren (mig via iPad) indtaster legitimationsoplysningerne, er de synlige både i Ettercap og i Trådbark (værktøj til netværkstrafikanalyse).

angreb #2: Fortsat vores rolle som angriber af denne applikation har vi nu legitimationsoplysningerne for brugeren hgraves med adgangskode P4SSW0RD. Du kan se, at ikke kun denne applikation ikke bruger TLS, den har en meget svag adgangskodepolitik, der gør det muligt for brugerne at vælge virkelig forfærdelige adgangskoder.

vi logger ind ved hjælp af legitimationsoplysningerne ovenfor og kan se et inputfelt med mulighed for at søge efter liste over personer. Når du trykker på Search, får vi den fulde liste over mennesker. Hvis vi for eksempel sætter “Fra”, får vi filtrerede resultater baseret på søgning. Hvad hvis vi sætter der nogle ulovlige karakter? Det er indlysende, at der er nogle database bag denne ansøgning, så lad os prøve ' tegn:

ikke kun mislykkedes dette, men vi kan se, at POST anmodning er mislykket med meget specifik fejlmeddelelse, der afslører strukturen af hele kvm-erklæringen. Vi kan se, at WHERE P.NAME LIKE '%'%' bruges i slutningen.

dygtig hacker behøver ikke mere. Justering af søgestrengen kan efter få forsøg give disse resultater:

injektionen i dette tilfælde skabte union for at vælge erklæring, der henter brugernavne og adgangskoder sammen med deres rolle. Ikke kun dette var vellykket, vi har formået at vise det i den oprindelige klientapplikation.

vi har nu legitimationsoplysninger for alle brugere og deres roller (vist af heltal i kolonnen “alder”). Hvis hframe har rolle 1, skal rgraves derfor være vigtigere bruger med rolle 3.

angreb #3: Attacking svagt hashede adgangskoder

vi har lært i det første angreb, at der sandsynligvis ikke er nogen adgangskodepolitik indstillet til denne applikation. Dette ville give os håb om, at rgraves heller ikke lægger for meget vægt på sikkerhed.

den nemmeste måde at knække hash af adgangskode, der bruger utilstrækkelig hashing algoritme (som MD5 i dette tilfælde) er at udføre ordbog eller regnbue bord angreb. Der er mange muligheder, men den nemmeste er at bruge internettjenester, der allerede har en stor database med adgangskode-til-hash-kombinationer:

den første er hframe, den anden er rgraves. smorgan synes at bruge stærkere adgangskoder end andre, da det ikke er i ordbogen.

du kan se, at adgangskoden til rgraves er sværdfisk, hvilket betyder, at han ikke nu, hvor vigtigt det er at vælge ikke-Ordbog adgangskode ;). Nu forhindrer intet os i at logge ind som denne bruger og opdage afsnittet” admin ” og fortrolige oplysninger:

læs ikke dette, hvis du er tysk 🙂

Sådan løses dette?

du kan måske sige, at alt dette let kunne forhindres. Man kan sige, at disse var rookie fejl. Nå, det kan være sandt, men det er også sandt, at det åbne Programsikkerhedsprojekt viser injektion som #1 sårbarhed i internetapplikationer (og det har været sådan i flere år).

så hvis du fandt dig selv undrende, hvordan du forhindrer alt dette, lad os opsummere:

• Brug altid SSL / TLS, når du sender noget til serveren. Det behøver ikke at være legitimationsoplysninger, det betragtes i øjeblikket som god praksis generelt. Selvom du slet ikke har nogen input på din side! Den nemmeste måde er at levere certifikat via tjenester som Let ‘ s Encrypt.
• Husk, at selvsignerede certifikater kan afbøde spørgsmålet om dataeksponering, men forhindrer ikke MITM-angriberen i at falske hele siden med sit eget selvsignerede certifikat helt.
• når der beskæftiger sig med forespørgsler altid undslippe parametre opnået fra klient. I foråret kan du bruge NamedParameterJdbcTemplate, som også er god til læsbarhed.
• vær paranoid. Valider enhver brugerinput. Igen i Java / Spring verden kan du tilføje valideringsregler ved hjælp af JSR-380 Bean Validering implementering ligesom Hibernate validator og anmærke parametre, f.eks @Pattern(regexp = "*") String name ville forhindre indtastning '.
• Log eventuelle forsøg på at videregive ugyldig input i programmet. I tilfælde af fejl må du desuden ikke udsætte nogen implementeringsspecifikke oplysninger for klienten.
• forbedre din godkendelse.
  • brug om muligt mindst 2-faktor-godkendelse.
  • implementer ikke brugerdefineret adgangskodelagring eller krypteringsalgoritmer. Det er ekstremt svært at gøre på egen hånd, og du vil helt sikkert mislykkes. Der er gennemprøvede løsninger som BCrypt.
• Læs og bogmærke top 10. Start med der og derefter gå gennem deres liste over bedste praksis.