Un cop d'ull a l'explotació de vulnerabilitats

Com em vaig quedar amb ganes de seguir tractant sobre aquest tema, permetin-me explicar una mica d'història, teoria i pràctica sobre les vulnerabilidaes. Tots hem sentit a hores d'ara que les fallades de seguretat poden costar molt, tots sabem que hem de mantenir el nostre programari actualitzat, tots sabem que moltes actualitzacions es produeixen per errors de seguretat. Però avui els explicaré una mica sobre com és que es troben i s'exploten aquests errors 🙂 Però abans d'això anem a aclarir uns quants detalls per poder tenir un millor panorama.

Abans de començar

Primer vull dir-los que ens centrarem en la primera vulnerabilitat que vaig aprendre a explotar, els coneguts buffer overflows, En aquesta vulnerabilitat vam aprofitar una falta de verificació en la memòria per fer coses divertides 🙂 Però anem a aclarir una mica més a l'respecte.

Això no serà un escenari de el món real

No puc donar-me el luxe de ensenyar-los a trencar qualsevol programa que vegin 🙂 primer perquè és perillós per als seus ordinadors, segon perquè això em prendria més de la meva acostumada quota de paraules.

Ens anem de viatge als 80s

Això que els vaig a mostrar el puc fer en el meu portàtil, però no vol dir que es pugui fer avui per avui de manera senzilla 🙂 molts d'aquests conceptes ja han estat explotats tantes vegades que han sorgit nous mètodes de protecció i nous mètodes per evadir 😛 però això ens torna a al mateix lloc, falta espai per poder explicar tot això 🙂

Potser no funcioni en el teu processador

Encara vaig a utilitzar un exemple molt simple, vull que des del principi quedi prou clar que els detalls d'això són tants i tan variats que així com pot sortir-te igual que a mi, si desitges intentar-ho, també pot ser que no s'aconsegueixi l'efecte desitjat 🙂 Però ja s'imaginaran que això no puc explicar-ho en aquest espai, sobretot perquè amb aquesta introducció ja em vaig endur més de 300 paraules, així que directe a la nostra.

Què és un buffer Overflow

Per respondre això primer hem de comprendre la primera meitat d'aquesta combinació.

Buffers

Com tot es tracta de memòria en un equip computacional, és lògic que hi ha d'haver algun tipus de contenidor d'informació. Quan parlem de entrades o sortides, Arribem directament a l'concepte de tampons. Per fer-ho curt, XNUMX esmorteir és un espai de memòria de mida definit en el qual anem a emmagatzemar una quantitat d'informació, simple 🙂

Els overflow ocorren, com el seu nom indica, quan un buffer s'omple amb més informació de la que pot aguantar. Però, per què és això important?

Apilar

També conegut com piles, són un tipus de dades abstracte en el qual podem apilar informació, la seva principal característica és que compten amb un ordenament LIFO (Last In First Out). Pensem per un segon en una pila de plats, nosaltres els posem per sobre un a un, i després els traiem XNUMX-XNUMX des de dalt, això fa que l'últim plat que hàgim posat (el qual es troba fins a dalt) sigui el primer plat que traurem, evidentment si només podem treure un plat a la vegada i vam decidir fer-ho en aquest ordre: P.

Ara que ja coneixen aquests dos conceptes, hem de ordenar-los. Les piles són importants perquè cada programa que executem té la seva pròpia pila d'execució. Però aquesta pila té una característica particular, creix cap avall. L'única cosa que han de saber d'això és que mentre un programa s'executa, quan una funció és cridada, la pila passa d'un nombre X de memòria a un nombre (Xn). Però per poder seguir hem de comprendre un concepte més.

punters

Aquest és un concepte que torna boig a molts programadors quan comencen en el món de C, francament la gran potència de la programació en C es deu en part a l'ús de punters. Per fer-ho simple, un punter apunta a una adreça de memòria. Això sona complex, però no ho és tant, tots tenim RAM en les nostres màquines cert? Doncs aquesta pot definir com un arranjament consecutiu de blocs, Normalment aquestes ubicacions s'expressen en nombres hexadecimals (de el 0 a 9 i després d'això de A a F, com ara 0x0, 0x1, 0x6, 0XA, 0xF, 0x10). Aquí com a nota curiosa, 0x10 NO és igual a 10 😛 si ho convertim a l'ordre decimal seria el mateix que dir 15. Això és una cosa que també confon més d'un a del principi, però anem a la nostra.

Inscripció i registre al càmping

Els processadors treballen amb una sèrie de registres, Els quals funcionen per transmetre ubicacioines des de la memòria física a l'processador, per a arquitectures que fan servir 64-bits, la quantitat de registres és gran i difícil de descriure aquí, però per fer-nos a la idea, els registres són com punters, indiquen entre altres coses, un espai en memòria (ubicació).

Ara la pràctica

Sé que ha estat molta informació per processar fins ara, però en realitat són temes una mica complexos que intento explicar de manera molt simple, anem a veure un petit programa que fa servir buffers i ho anem a trencar per entendre això dels overflows, evidentment aquest no és un programa real, i anem a «evadir» moltes de les contramesures que es fan servir avui dia, només per mostrar com es feien les coses abans 🙂 i perquè alguns d'aquests principis són necessaris per poder aprendre coses més complexes 😉

BGF

Un gran programa que és sens dubte un dels més usats per programadors en C. Entre les seves múltiples virtuts tenim el fet que ens permet veure tot això que hem estat conversant fins ara, registres, la pila, buffers, etc 🙂 Anem a veure el programa que farem servir per al nostre exemple.

retinput.c

Aquest és un programa bastant simple, farem servir la llibreria stdio.h per poder obtenir informació i mostrar-la en un terminal. Podem veure una funció anomenada return_input la qual genera un esmorteir anomenat formació, Que té una longitud de 30 octets (El tipus de dada char és d'1 byte de llarg).

la funció gets(array); sol·licita informació per consola i la funció printf() retorna el contingut d'array i el mostra en pantalla.

Tot programa escrit en C comença per la funció main(), Aquesta només es va a encarregar de cridar a return_input, ara anem a compilar el programa.

Anem a desprendre una mica del que acabo de fer. l'opció -ggdb li indica a gcc que ha de compilar el programa amb informació perquè gdb sigui capaç de realitzar un debug adequat. -fno-stack-protector és una opció que evidentment no hauríem d'estar fent servir, però que farem servir perquè en cas contrari ens seria possible genererar el buffer overflow al stack. A la fin he provat el resultat. ./a.out només executa el que acabo de compilar, em demana informació i la devuele. funcionant 🙂

Advertències

Una altra nota aquí. Poden veure les advertències? clarament és una cosa a tenir en compte quan treballem amb codi o compilem, aquesta és una mica òbvia i són pocs els programes que avui dia tenen la funció gets() en el codi. Un avantatge de Gentoo és que a l'compilar cada programa, puc veure el que pot estar malament, un programa «ideal» no hauria de tenir-les, però els sorprendria quants programes grans tenen aquestes advertències perquè simplement són MOLT grans i és difícil mantenir el rastre de les funcions perilloses quan són moltes advertències a el mateix temps. Ara si seguim

Depurant el programa

Ara, aquesta part pot ser una mica confusa, però com ja he escrit prou, no puc donar-me el luxe de explicar-ho tot, així que perdó si veuen que vaig molt ràpid 🙂

Desarmant el codi

Anem a començar veient el nostre programa compilat en llenguatge màquina.

Aquest és el codi de la nostra funció main en Muntatge, Això és el que entén el nostre processador, la línia de l'esquerra és l'adreça física en memòria, el <+ N> es coneix com offset, Bàsicament la distància des del principi de la funció (main) fins a aquesta instrucció (conegut com codi d'operació). Després veiem el tipus d'instrucció (push / mov / callq ...) i un o més registres. Resumit podem dir que és la indicació seguida de la font / origen i la destinació. <return_input> fa referència a la nostra segona funció, anem a donar-li un cop d'ull.

Return_input

Aquesta és una mica més complexa, però només vull que revisin un parell de coses, hi ha un label anomenat <gets@plt> i un últim opcode anomenat retq que indica el final de la funció. Anem a posar un parell de breakpoints, un a la funció gets i un altre al retq.

Correr

Ara anem a córrer el programa per veure com comença a començar l'acció.

Podem veure que apareix una petita fletxa que indica el opcode on ens trobem, vull que tinguin en compte la direcció 0x000055555555469b, Aquesta és l'adreça que es troba després de la crida a return_input en la funció main , Això és important ja que aquí és on hauria de tornar el programa quan acabi de rebre el entrada, Entrarem en la funció. Ara anem a revisar la memòria abans d'entrar a la funció gets.

Els he tornat a posar la funció main dalt, i he ressaltat el codi a què em referia, com poden veure, a causa de l' Endianness s'ha separat en dos segments, vull que tinguin en compte la direcció 0x7fffffffdbf0 (La primera de l'esquerra després del commando x/20x $rsp) Ja que aquesta és la ubicació que hem de fer servir per revisar el resultat de gets, seguim:

Trencant el programa

He ressaltat aquests 0x44444444perquè són la representació de les nostres Ds 🙂 ara hem començat a afegir entrada a el programa, i com poden apreciar, estem a només dos línies de la nostra direcció desitjada, anem a omplir-fins a estar just abans de les adreces que ressaltem en el pas anterior.

Canviant la ruta de retorn

Ara que hem aconseguit entrar en aquesta secció de el codi on indica el retorn de la funció, anem a veure què passa si canviem la direacción 🙂 en lloc d'anar a la ubicació de l'opcode que segueix a què teníem fa un moment, què els sembla si regreamos a return_input? Però per això, cal escriure en binari la direacción que desitgem, ho farem amb la funció printf de bash 🙂

Ara hem rebut dues vegades la informació 😀 segurament el programa no estava fet per a això, però hem aconseguit trencar el codi i fer que repeteixi alguna cosa que no se suposava que faci.

reflexions

Aquest simple canvi pot considerar-se un explotar molt bàsic 🙂 ha aconseguit trencar el programa i fer alguna cosa que nosaltres desitgem que faci.

Aquest és només el primer pas en una quasi infinita llista de coses per veure i afegir, hi ha formes d'afegir més coses que simplement repetir una ordre, però aquesta vegada he escrit molt i tot el relacionat a shellcoding és un tema per escriure més que articles, llibres complets diria jo. Disculpin si no he pogut aprofundir una mica més en temes que m'haguessin agradat, però segur ja hi haurà oportunitat 🙂 Salutacions i gràcies per arribar fins aquí.