Translated ['src/generic-methodologies-and-resources/phishing-methodolog

This commit is contained in:
Translator 2025-09-29 23:33:43 +00:00
parent 435facbc2a
commit d939f48b8c
4 changed files with 228 additions and 106 deletions

1
.gitignore vendored
View File

@ -11,3 +11,4 @@ book
book/*
hacktricks-preprocessor.log
hacktricks-preprocessor-error.log
searchindex.js

View File

@ -3,95 +3,108 @@
{{#include ../../banners/hacktricks-training.md}}
## iOS Kupunguza Exploits
- **Code Signing** katika iOS inafanya kazi kwa kuhitaji kila kipande cha msimbo wa utekelezaji (apps, libraries, extensions, n.k.) kusainiwa kwa kisayansi na cheti kinachotolewa na Apple. Wakati msimbo unapoandikwa, iOS inathibitisha saini ya kidigital dhidi ya root inayotambulika ya Apple. Ikiwa saini si sahihi, haipo, au imerekebishwa, OS inakataza kuutumia. Hii inazuia mashambulizi ya kuingiza msimbo hatarishi ndani ya apps halali au kuendesha binaries zisizosainiwa, kwa ufanisi kuvunja sehemu kubwa za minyororo ya exploit zinazotegemea kuendesha msimbo wa kukamata au uliobadilishwa.
- **CoreTrust** ni subsystem ya iOS inayotekeleza uthibitisho wa code signing wakati wa runtime. Inathibitisha saini moja kwa moja kwa kutumia cheti la root la Apple bila kutegemea cached trust stores, ikimaanisha binaries zilizosasishwa na Apple (au zilizo na entitlements sahihi) ndizo zinaweza kutekeleza. CoreTrust inahakikisha kwamba hata kama mshambuliaji atabadili app baada ya kusakinishwa, kurekebisha system libraries, au kujaribu kupakia msimbo usiosainiwa, mfumo utazuia utekelezaji isipokuwa msimbo bado umehifadhiwa kwa usahihi. Utekelezaji mgumu huu unafunga njia nyingi za post-exploitation ambazo toleo la zamani la iOS liliwaruhusu kupitia ukaguzi dhaifu au unaoweza kupitishwa.
- **Data Execution Prevention (DEP)** inachukua maeneo ya kumbukumbu kuwa yasitekelezeke isipokuwa yakitakiwa kuwa na msimbo. Hii inazuia mashambulizi ya kuingiza shellcode ndani ya sehemu za data (kama stack au heap) na kuirusha, ikiwalazimu kutumia mbinu tata kama ROP (Return-Oriented Programming).
- **ASLR (Address Space Layout Randomization)** inabadilisha kwa nasibu anwani za kumbukumbu za msimbo, libraries, stack, na heap kila wakati mfumo unapoanza. Hii inafanya kuwa vigumu kwa mshambuliaji kutabiri wapi maagizo au gadgets muhimu ziko, ikivunja minyororo mingi ya exploit zinazotegemea mipangilio thabiti ya kumbukumbu.
- **KASLR (Kernel ASLR)** inahusu wazo lile lile la randomness kwa kernel ya iOS. Kwa kupangusa anwani ya msingi ya kernel kila boot, inazuia mashambulizi kupata kwa uhakika kazi au miundo ya kernel, na kuongeza ugumu wa explots za ngazi ya kernel ambazo zingekuwa zinapata udhibiti kamili wa mfumo.
- **Kernel Patch Protection (KPP)** pia inajulikana kama **AMCC (Apple Mobile File Integrity)** katika iOS, inafuatilia mara kwa mara kurasa za msimbo wa kernel kuhakikisha hazijabadilishwa. Ikiwa kutamwidihishwa kutambuliwa—kama exploit inayojaribu kubadilisha kazi za kernel au kuingiza msimbo hatarishi—kifaa kitashangaa mara moja na kurudisha boot. Ulinzi huu unafanya exploits za kernel zenye kudumu kuwa ngumu zaidi, kwani mashambulizi hayawezi tu ku-hook au ku-patch maagizo ya kernel bila kusababisha crash ya mfumo.
- **Kernel Text Readonly Region (KTRR)** ni sifa ya usalama inayotokana na vifaa iliyotangazwa kwenye vifaa vya iOS. Inatumia memory controller ya CPU kuashiria eneo la msimbo (text) la kernel kuwa kwa kusomeka tu baada ya boot. Mara limefungwa, hata kernel yenyewe haiwezi kubadilisha eneo hili la kumbukumbu. Hii inazuia mashambulizi—na hata msimbo ulio na vibali vya juu—kutengeneza patch za maagizo ya kernel wakati wa runtime, ikifunga daraja kubwa la exploits zinazotegemea kubadilisha msimbo wa kernel moja kwa moja.
- **Pointer Authentication Codes (PAC)** hutumia saini za kriptografia zilizowekwa ndani ya bits zisizotumika za pointers kuthibitisha uadilifu wao kabla ya matumizi. Wakati pointer (kama return address au function pointer) inaundwa, CPU ina-isaini kwa funguo ya siri; kabla ya dereference, CPU inakagua saini. Ikiwa pointer imebadilishwa, ukaguzi unashindwa na utekelezaji unasimama. Hii inazuia mshambuliaji kuunda kwa udanganyifu au kutumia pointers zilizoharibika katika memory corruption exploits, ikifanya mbinu kama ROP au JOP ziwe ngumu zaidi kutekelezwa kwa ufanisi.
- **Privilege Access never (PAN)** ni sifa ya vifaa inayozuia kernel (hali ya privilage) kutoka kupata moja kwa moja kumbukumbu ya user-space isipokuwa ikiwa kwa wazi inawasha ufikiaji. Hii inazuia mashambulizi yaliyopata kuendesha msimbo wa kernel kwa urahisi kusoma au kuandika kumbukumbu ya user ili kupandisha hadhi au kuiba data nyeti. Kwa kutekeleza mgawanyiko mkali, PAN inapunguza athari za exploits za kernel na kuzuia mbinu nyingi za kawaida za kuongezeka kwa hadhi.
- **Page Protection Layer (PPL)** ni utaratibu wa usalama wa iOS unaolinda maeneo muhimu yanayosimamiwa na kernel, hasa yale yanayohusiana na code signing na entitlements. Inatekeleza ulinzi mkali wa uandishi kwa kutumia MMU (Memory Management Unit) na ukaguzi wa ziada, ikihakikisha kwamba hata msimbo wa kernel wenye privilage hauwezi kubadilisha kurasa nyeti kiholela. Hii inazuia mashambulizi yaliyopata utekelezaji wa ngazi ya kernel kutengeneza udhibiti wa miundo muhimu ya usalama, na kufanya kudumu na kuruka code-signing kuwa ngumu zaidi.
## Physical use-after-free
Hii ni muhtasari wa chapisho kutoka [https://alfiecg.uk/2024/09/24/Kernel-exploit.html](https://alfiecg.uk/2024/09/24/Kernel-exploit.html); zaidi ya hayo, taarifa za ziada kuhusu exploit inayotumia tekniki hii zinapatikana katika [https://github.com/felix-pb/kfd](https://github.com/felix-pb/kfd)
This is a summary from the post from [https://alfiecg.uk/2024/09/24/Kernel-exploit.html](https://alfiecg.uk/2024/09/24/Kernel-exploit.html) moreover further information about exploit using this technique can be found in [https://github.com/felix-pb/kfd](https://github.com/felix-pb/kfd)
### Usimamizi wa kumbukumbu katika XNU <a href="#memory-management-in-xnu" id="memory-management-in-xnu"></a>
### Memory management in XNU <a href="#memory-management-in-xnu" id="memory-management-in-xnu"></a>
**virtual memory address space** kwa michakato ya mtumiaji kwenye iOS inashughulikia anuwai kutoka **0x0 hadi 0x8000000000**. Hata hivyo, anwani hizi hazitafsiri moja kwa moja kuwa kumbukumbu ya kimwili. Badala yake, **kernel** hutumia **page tables** kutafsiri anwani za virtual kuwa **physical addresses** halisi.
The **virtual memory address space** for user processes on iOS spans from **0x0 to 0x8000000000**. However, these addresses dont directly map to physical memory. Instead, the **kernel** uses **page tables** to translate virtual addresses into actual **physical addresses**.
#### Ngazi za Page Tables katika iOS
#### Levels of Page Tables in iOS
Page tables zimepangwa kwa muundo wa mlolongo katika ngazi tatu:
Page tables are organized hierarchically in three levels:
1. **L1 Page Table (Level 1)**:
* Kila entry hapa inawakilisha anuwai kubwa ya virtual memory.
* Inafunika **0x1000000000 bytes** (au **256 GB**) ya virtual memory.
* Each entry here represents a large range of virtual memory.
* It covers **0x1000000000 bytes** (or **256 GB**) of virtual memory.
2. **L2 Page Table (Level 2)**:
* Entry hapa inawakilisha eneo ndogo ya virtual memory, haswa **0x2000000 bytes** (32 MB).
* Kuingia kwa L1 kunaweza kuonyesha kwenye L2 table ikiwa haifanyi mapping ya eneo zima yenyewe.
* An entry here represents a smaller region of virtual memory, specifically **0x2000000 bytes** (32 MB).
* An L1 entry may point to an L2 table if it can't map the entire region itself.
3. **L3 Page Table (Level 3)**:
* Hii ni ngazi ya mwisho, ambapo kila entry inamezea ukurasa mmoja wa kumbukumbu wa **4 KB**.
* Entry ya L2 inaweza kuonyesha kwenye L3 table ikiwa inahitajika udhibiti wa undani zaidi.
* This is the finest level, where each entry maps a single **4 KB** memory page.
* An L2 entry may point to an L3 table if more granular control is needed.
#### Kuweka Mapping ya Virtual kwa Physical Memory
#### Mapping Virtual to Physical Memory
* **Direct Mapping (Block Mapping)**:
* Baadhi ya entry katika page table zinamap moja kwa moja anuwai za anwani za virtual kwa anuwai inayoendelea ya anwani za physical (kama njia fupi).
* Some entries in a page table directly **map a range of virtual addresses** to a contiguous range of physical addresses (like a shortcut).
* **Pointer to Child Page Table**:
* Ikiwa inahitajika udhibiti wa kina, entry katika ngazi moja (mfano, L1) inaweza kuelekeza kwenye **child page table** kwenye ngazi inayofuata (mfano, L2).
* If finer control is needed, an entry in one level (e.g., L1) can point to a **child page table** at the next level (e.g., L2).
#### Mfano: Kuweka Mapping ya Anwani ya Virtual
#### Example: Mapping a Virtual Address
Tuseme unajaribu kupata anwani ya virtual **0x1000000000**:
Lets say you try to access the virtual address **0x1000000000**:
1. **L1 Table**:
* Kernel inakagua entry ya L1 inayohusiana na anwani hii ya virtual. Ikiwa ina **pointer to an L2 page table**, inaendelea kwa L2 table hiyo.
* The kernel checks the L1 page table entry corresponding to this virtual address. If it has a **pointer to an L2 page table**, it goes to that L2 table.
2. **L2 Table**:
* Kernel inakagua L2 page table kwa mapping ya undani zaidi. Ikiwa entry hii inaonyesha kwenye **L3 page table**, inaendelea huko.
* The kernel checks the L2 page table for a more detailed mapping. If this entry points to an **L3 page table**, it proceeds there.
3. **L3 Table**:
* Kernel inatafuta entry ya mwisho ya L3, ambayo inaonyesha kwenye **physical address** ya ukurasa wa kumbukumbu halisi.
* The kernel looks up the final L3 entry, which points to the **physical address** of the actual memory page.
#### Mfano wa Mapping ya Anwani
#### Example of Address Mapping
Ikiwa unaandika anwani ya physical **0x800004000** kwenye index ya kwanza ya L2 table, basi:
If you write the physical address **0x800004000** into the first index of the L2 table, then:
* Anwani za virtual kutoka **0x1000000000** hadi **0x1002000000** zinamap kuwa anwani za physical kutoka **0x800004000** hadi **0x802004000**.
* Hii ni **block mapping** kwenye ngazi ya L2.
* Virtual addresses from **0x1000000000** to **0x1002000000** map to physical addresses from **0x800004000** to **0x802004000**.
* This is a **block mapping** at the L2 level.
Vinginevyo, ikiwa entry ya L2 inaonyesha kwenye L3 table:
Alternatively, if the L2 entry points to an L3 table:
* Kila ukurasa wa 4 KB katika anuwai ya virtual **0x1000000000 -> 0x1002000000** utapangwa na entry za kibinafsi katika L3 table.
* Each 4 KB page in the virtual address range **0x1000000000 -> 0x1002000000** would be mapped by individual entries in the L3 table.
### Physical use-after-free
A **physical use-after-free** (UAF) hutokea wakati:
A **physical use-after-free** (UAF) occurs when:
1. Mchakato unafanya **allocate** kumbukumbu fulani kama inayoweza kusomwa na kuandikwa (readable and writable).
2. **page tables** zinasasishwa ili kumap kumbukumbu hii kwa anwani mahususi za physical ambazo mchakato anaweza kufikia.
3. Mchakato **huondoa** (hutoa/free) kumbukumbu hiyo.
4. Hata hivyo, kutokana na **bug**, kernel **inasahau kuondoa mapping** kutoka page tables, ingawa inatambua kumbukumbu ya physical kama huru.
5. Kernel inaweza kisha **kureallocate kumbukumbu ya physical iliyotolewa** kwa matumizi mengine, kama data za kernel.
6. Kwa sababu mapping haikuondolewa, mchakato bado anaweza **kusoma na kuandika** kwenye kumbukumbu hiyo ya physical.
1. A process **allocates** some memory as **readable and writable**.
2. The **page tables** are updated to map this memory to a specific physical address that the process can access.
3. The process **deallocates** (frees) the memory.
4. However, due to a **bug**, the kernel **forgets to remove the mapping** from the page tables, even though it marks the corresponding physical memory as free.
5. The kernel can then **reallocate this "freed" physical memory** for other purposes, like **kernel data**.
6. Since the mapping wasnt removed, the process can still **read and write** to this physical memory.
Hii ina maana mchakato unaweza kufikia **kurasa za kumbukumbu za kernel**, ambazo zinaweza kuwa na data nyeti au miundo, na hivyo kumuwezesha mshambuliaji **kuingilia kumbukumbu ya kernel**.
This means the process can access **pages of kernel memory**, which could contain sensitive data or structures, potentially allowing an attacker to **manipulate kernel memory**.
### IOSurface Heap Spray
Kwa kuwa mshambuliaji hawezi kudhibiti ni kurasa gani za kernel zitapewa kumbukumbu iliyotolewa, wanatumia mbinu inayoitwa **heap spray**:
Since the attacker cant control which specific kernel pages will be allocated to freed memory, they use a technique called **heap spray**:
1. Mshambuliaji **huunda idadi kubwa ya vitu vya IOSurface** kwenye kumbukumbu ya kernel.
2. Kila objektu la IOSurface lina thamani ya **magic** katika moja ya fields zake, kufanya iwe rahisi kutambua.
3. Wanapiga **skana kurasa zilizotolewa** ili kuona kama baadhi ya vitu vya IOSurface vimeangukia kwenye ukurasa uliotolewa.
4. Wakitambua objektu la IOSurface kwenye ukurasa uliotolewa, wanaweza kulitumia **kusoma na kuandika kumbukumbu ya kernel**.
1. The attacker **creates a large number of IOSurface objects** in kernel memory.
2. Each IOSurface object contains a **magic value** in one of its fields, making it easy to identify.
3. They **scan the freed pages** to see if any of these IOSurface objects landed on a freed page.
4. When they find an IOSurface object on a freed page, they can use it to **read and write kernel memory**.
Taarifa za ziada kuhusu hili ziko katika [https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups)
More info about this in [https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups)
> [!TIP]
> Fahamu kuwa vifaa vya iOS 16+ (A12+) vina utatuzi wa kiapparatus (kama PPL au SPTM) unaofanya mbinu za physical UAF zisifae kwa urahisi.
> PPL inatekeleza ulinzi mkali wa MMU kwa kurasa zinazohusiana na code signing, entitlements, na data nyeti za kernel, hivyo, hata ukireuse ukurasa, uandishi kutoka userland au kernel iliyovamiwa kwenda kwenye kurasa zilizo chini ya ulinzi wa PPL unatokwama.
> Secure Page Table Monitor (SPTM) inaongeza PPL kwa kuimarisha sasisho za page table yenyewe. Inahakikisha kwamba hata code yenye vibali vya juu ya kernel haiwezi kuremap kwa kimya kurasa zilizotolewa au kuharibu mappings bila kupitia ukaguzi wa usalama.
> KTRR (Kernel Text Read-Only Region), ambayo inafunga sehemu ya code ya kernel kama read-only baada ya boot. Hii inazuia mabadiliko yoyote ya runtime kwa code ya kernel, ikifunga njia kubwa ya shambulio ambayo exploit za physical UAF mara nyingi hutegemea.
> Zaidi ya hayo, allocations za `IOSurface` ziko ngumu kutabirika na vigumu kuzifanikiwa kuzipanga katika maeneo yanayoweza kufikiwa na user, ambayo inafanya mbinu ya “magic value scanning” isitegemeeke sana. Na `IOSurface` sasa inatwaliwa na entitlements na vizuizi vya sandbox.
> Fahamu kwamba vifaa vya iOS 16+ (A12+) vina mitigations za hardware (kama PPL au SPTM) zinazofanya mbinu za physical UAF zisifae vizuri.
> PPL inatekeleza ulinzi mkali wa MMU kwenye kurasa zinazohusiana na code signing, entitlements, na data nyeti za kernel, kwa hivyo, hata kama ukurasa unatumika tena, maandishi kutoka userland au msimbo wa kernel uliotatizwa kwa kurasa za PPL yanazuia.
> Secure Page Table Monitor (SPTM) inaongeza ulinzi kwa PPL kwa kuimarisha masasisho ya page table yenyewe. Inahakikisha kwamba hata msimbo mwenye privilage wa kernel hauwezi kupindisha au kugusa mappings bila kupitia ukaguzi ulio salama.
> KTRR (Kernel Text Read-Only Region), ambayo inalinda sehemu ya msimbo wa kernel kama read-only baada ya boot. Hii inazuia mabadiliko yoyote ya runtime kwa msimbo wa kernel, ikifunga njia kuu ya shambulio ambazo physical UAF exploits mara nyingi hutegemea.
> Zaidi ya hayo, allocations za `IOSurface` ni ngumu zaidi kutabiri na ngumu kuvutia kwa maeneo yanayoweza kupatikana kwa user, ambayo inafanya mbinu ya kuchunguza “magic value” kuwa sio ya kuaminika. Na `IOSurface` sasa inalindwa kwa entitlements na vizuizi vya sandbox.
### Step-by-Step Heap Spray Process
1. **Spray IOSurface Objects**: Mshambuliaji huunda vitu vingi vya IOSurface zikiwa na kitambulisho maalum ("magic value").
2. **Scan Freed Pages**: Wanakagua kama yoyote ya vitu imepangwa kwenye ukurasa uliotolewa.
3. **Read/Write Kernel Memory**: Kwa kuibadilisha fields katika objektu la IOSurface, wanapata uwezo wa kufanya **arbitrary reads and writes** katika kumbukumbu ya kernel. Hii inawawezesha:
* Kutumia field moja kusoma **kima chochote cha 32-bit** katika kumbukumbu ya kernel.
* Kutumia field nyingine kuandika thamani za **64-bit**, wakipata primitive thabiti ya **kernel read/write**.
1. **Spray IOSurface Objects**: The attacker creates many IOSurface objects with a special identifier ("magic value").
2. **Scan Freed Pages**: They check if any of the objects have been allocated on a freed page.
3. **Read/Write Kernel Memory**: By manipulating fields in the IOSurface object, they gain the ability to perform **arbitrary reads and writes** in kernel memory. This lets them:
* Use one field to **read any 32-bit value** in kernel memory.
* Use another field to **write 64-bit values**, achieving a stable **kernel read/write primitive**.
Generate IOSurface objects with the magic value IOSURFACE\_MAGIC to later search for:
```c
@ -114,7 +127,7 @@ io_connect_t id = result.surface_id;
}
}
```
Tafuta vitu vya **`IOSurface`** katika ukurasa wa kimwili mmoja ulioachiliwa:
Tafuta vitu vya **`IOSurface`** kwenye ukurasa mmoja wa kimwili uliotolewa:
```c
int iosurface_krw(io_connect_t client, uint64_t *puafPages, int nPages, uint64_t *self_task, uint64_t *puafPage) {
io_connect_t *surfaceIDs = malloc(sizeof(io_connect_t) * 0x4000);
@ -148,25 +161,25 @@ free(surfaceIDs);
return 0;
}
```
### Kupata Kernel Read/Write kwa kutumia IOSurface
### Kupata Kusoma/Kuandika Kernel kwa kutumia IOSurface
Baada ya kupata udhibiti wa object ya IOSurface katika kernel memory (mapped to a freed physical page accessible from userspace), tunaweza kuvitumia kwa ajili ya **arbitrary kernel read and write operations**.
Baada ya kupata udhibiti wa kipengee cha IOSurface katika kernel memory (mapped to a freed physical page accessible from userspace), tunaweza kukitumia kwa **operesheni za kusoma na kuandika kernel kwa hiari**.
**Sehemu Muhimu katika IOSurface**
The IOSurface object has two crucial fields:
Kipengee cha IOSurface kina sehemu mbili muhimu:
1. **Use Count Pointer**: Inaruhusu **32-bit read**.
2. **Indexed Timestamp Pointer**: Inaruhusu **64-bit write**.
1. **Use Count Pointer**: Inaruhusu **kusoma 32-bit**.
2. **Indexed Timestamp Pointer**: Inaruhusu **kuandika 64-bit**.
Kwa kuandika upya pointers hizi, tunazituma kwa anwani zozote katika kernel memory, hivyo kuwezesha operesheni za read/write.
Kwa kuandika upya pointer hizi, tunaziwekea anwani za hiari katika kernel memory, hivyo kuwezesha uwezo wa kusoma/kuandika.
#### 32-Bit Kernel Read
#### Kusoma 32-Bit ya Kernel
Ili kufanya kusoma:
1. Andika upya **use count pointer** ili iashirie anwani lengwa ikipunguzwa kwa offset ya 0x14-byte.
2. Tumia method ya `get_use_count` kusoma thamani kwenye anwani hiyo.
1. Andika upya **use count pointer** ili ijelekee kwa anwani lengwa ikiondoa offset ya 0x14-byte.
2. Tumia method `get_use_count` kusoma thamani kwenye anwani hiyo.
```c
uint32_t get_use_count(io_connect_t client, uint32_t surfaceID) {
uint64_t args[1] = {surfaceID};
@ -188,7 +201,7 @@ return value;
Ili kufanya uandishi:
1. Overwrite the **indexed timestamp pointer** kwa anwani lengwa.
1. Andika upya **indexed timestamp pointer** kwa anwani inayolengwa.
2. Tumia method `set_indexed_timestamp` kuandika thamani ya 64-bit.
```c
void set_indexed_timestamp(io_connect_t client, uint32_t surfaceID, uint64_t value) {
@ -203,13 +216,13 @@ set_indexed_timestamp(info.client, info.surface, value);
iosurface_set_indexed_timestamp_pointer(info.object, orig);
}
```
#### Exploit Flow Recap
#### Muhtasari wa Mtiririko wa Exploit
1. **Trigger Physical Use-After-Free**: Kurasa zilizofutwa zinaweza kutumika tena.
2. **Spray IOSurface Objects**: Tenga vitu vingi vya IOSurface na "magic value" ya kipekee katika kernel memory.
3. **Identify Accessible IOSurface**: Tafuta IOSurface kwenye freed page unayodhibiti.
4. **Abuse Use-After-Free**: Badilisha pointers katika IOSurface object ili kuwezesha arbitrary **kernel read/write** kupitia IOSurface methods.
1. **Trigger Physical Use-After-Free**: Kurasa zilizotolewa zinaweza kutumika tena.
2. **Spray IOSurface Objects**: Tenga IOSurface objects nyingi zenye "magic value" ya kipekee katika kernel memory.
3. **Identify Accessible IOSurface**: Tafuta IOSurface kwenye ukurasa uliotolewa unaodhibiti.
4. **Abuse Use-After-Free**: Badilisha vielekezo katika IOSurface object ili kuwezesha kwa hiari **kernel read/write** kupitia IOSurface methods.
Kwa primitives hizi, exploit inatoa controlled **32-bit reads** na **64-bit writes** kwa kernel memory. Hatua za ziada za jailbreak zinaweza kuhusisha read/write primitives imara zaidi, ambazo zinaweza kuhitaji kupitisha kinga za ziada (kwa mfano, PPL kwenye vifaa vipya vya arm64e).
Kwa primitives hizi, exploit hutoa kusoma za **32-bit** zilidhibitiwa na uandishi za **64-bit** kwa kernel memory. Hatua za ziada za jailbreak zinaweza kuhusisha primitives za kusoma/kuandika zenye utulivu zaidi, ambazo zinaweza kuhitaji kupita ulinzi wa ziada (mf., PPL kwenye vifaa vipya vya arm64e).
{{#include ../../banners/hacktricks-training.md}}

View File

@ -1,69 +1,147 @@
# Kugundua Phishing
# Kutambua Phishing
{{#include ../../banners/hacktricks-training.md}}
## Utangulizi
Ili kugundua jaribio la phishing ni muhimu **kuelewa mbinu za phishing zinazotumiwa leo**. Kwenye ukurasa wa mzazi wa chapisho hili, unaweza kupata taarifa hii, hivyo kama hujui ni mbinu zipi zinazotumiwa leo nakusihi uende kwenye ukurasa wa mzazi na usome angalau sehemu hiyo.
Ili kutambua jaribio la phishing ni muhimu **kuelewa phishing techniques zinazotumika sasa hivi**. Kwenye ukurasa mzazi wa chapisho hiki, unaweza kupata taarifa hizi, hivyo ikiwa hufahamu ni tekniki gani zinatumika leo ninakushauri uende kwenye ukurasa mzazi na usome angalau sehemu hiyo.
Chapisho hili linategemea wazo kwamba **washambuliaji watajaribu kwa namna fulani kuiga au kutumia jina la kikoa la mwathirika**. Ikiwa kikoa chako kinaitwa `example.com` na unapata phishing ukitumia jina la kikoa tofauti kabisa kwa sababu fulani kama `youwonthelottery.com`, mbinu hizi hazitakufichua.
Chapisho hili limetegemea wazo kwamba **washambuliaji watajaribu kwa namna fulani kuiga au kutumia jina la domain la mwathiriwa**. Ikiwa domain yako inaitwa `example.com` na umepigwa phishing ukitumia kwa sababu fulani domain tofauti kabisa kama `youwonthelottery.com`, mbinu hizi hazitatambua hilo.
## Mabadiliko ya majina ya kikoa
## Mabadiliko ya jina la domain
Ni rahisi **kufichua** jaribio hizo za **phishing** ambazo zitatumia jina la **kikoa linalofanana** ndani ya barua pepe.\
Inatosha **kuunda orodha ya majina ya phishing yanayoweza kutokea** ambayo mshambuliaji anaweza kutumia na **kuangalia** ikiwa yame **jiandikisha** au kuangalia ikiwa kuna **IP** inayotumia hilo.
Ni aina ya **rahisi** ku**gundua** yale majaribio ya **phishing** yatakayotumia **jina la domain linalofanana** ndani ya barua pepe.\
Inatosha **kutengeneza orodha ya majina ya phishing yanayowezekana zaidi** ambayo mshambuliaji anaweza kutumia na **kuangalia** ikiwa yameorodheshwa au angalia tu ikiwa kuna **IP** inayoyatumia.
### Kupata kikoa chenye shaka
### Kupata domain zenye kutiliwa shaka
Kwa kusudi hili, unaweza kutumia yoyote ya zana zifuatazo. Kumbuka kwamba zana hizi pia zitafanya maombi ya DNS kiotomatiki ili kuangalia ikiwa kikoa kina IP yoyote iliyotolewa:
Kwa kusudi hili, unaweza kutumia zana yoyote kati ya zifuatazo. Kumbuka kwamba zana hizi pia zitafanya maombi ya DNS moja kwa moja ili kuangalia ikiwa domain ina IP yoyote iliyotengwa:
- [**dnstwist**](https://github.com/elceef/dnstwist)
- [**urlcrazy**](https://github.com/urbanadventurer/urlcrazy)
Vidokezo: Ikiwa utatengeneza orodha ya wagombea, pia ingiza kwenye DNS resolver logs zako ili kugundua **NXDOMAIN lookups from inside your org** (watumiaji wakijaribu kufikia typo kabla mshambuliaji hajayasajili). Sinkhole or pre-block these domains if policy allows.
### Bitflipping
**Unaweza kupata maelezo mafupi ya mbinu hii kwenye ukurasa wa mzazi. Au soma utafiti wa asili katika** [**https://www.bleepingcomputer.com/news/security/hijacking-traffic-to-microsoft-s-windowscom-with-bitflipping/**](https://www.bleepingcomputer.com/news/security/hijacking-traffic-to-microsoft-s-windowscom-with-bitflipping/)
**You can find a short the explanation of this technique in the parent page. Or read the original research in** [**https://www.bleepingcomputer.com/news/security/hijacking-traffic-to-microsoft-s-windowscom-with-bitflipping/**](https://www.bleepingcomputer.com/news/security/hijacking-traffic-to-microsoft-s-windowscom-with-bitflipping/)
Kwa mfano, mabadiliko ya bit 1 katika kikoa microsoft.com yanaweza kubadilisha kuwa _windnws.com._\
**Washambuliaji wanaweza kujiandikisha kwa majina mengi ya kikoa yanayohusiana na mwathirika ili kuwahamisha watumiaji halali kwenye miundombinu yao**.
Kwa mfano, mabadiliko ya 1 bit kwenye domain microsoft.com yanaweza kuibadilisha kuwa _windnws.com._\
**Washambuliaji wanaweza kusajili kadri iwezekanavyo domain nyingi za bit-flipping zinazohusiana na mwathiriwa ili kupeleka watumiaji halali kwenye miundombinu yao**.
**Majina yote ya kikoa yanayoweza kubadilishwa yanapaswa pia kufuatiliwa.**
**All possible bit-flipping domain names should be also monitored.**
Ikiwa pia unahitaji kuzingatia homoglyph/IDN lookalikes (kwa mfano, kuchanganya herufi za Latin/Cyrillic), angalia:
{{#ref}}
homograph-attacks.md
{{#endref}}
### Ukaguzi wa Msingi
Mara tu unapokuwa na orodha ya majina ya kikoa yenye shaka unapaswa **kuangalia** (hasa bandari za HTTP na HTTPS) ili **kuona ikiwa wanatumia fomu ya kuingia inayofanana** na moja ya kikoa cha mwathirika.\
Unaweza pia kuangalia bandari 3333 kuona ikiwa iko wazi na inafanya kazi ya `gophish`.\
Ni muhimu pia kujua **umri wa kila kikoa chenye shaka kilichogunduliwa**, kadri inavyokuwa changa ndivyo inavyokuwa hatari zaidi.\
Unaweza pia kupata **picha za skrini** za ukurasa wa wavuti wa HTTP na/au HTTPS wenye shaka ili kuona ikiwa ni ya shaka na katika hali hiyo **ingia ili kuangalia kwa undani zaidi**.
Mara tu ukiwa na orodha ya majina ya domain yenye kutiliwa shaka unapaswa **kuzijaribu** (hasa ports HTTP na HTTPS) ili **kuona kama zinatumia fomu ya login inayofanana** na moja ya domain za mwathiriwa.\
Unaweza pia kuangalia port 3333 kuona ikiwa imefunguliwa na inaendesha mfano wa `gophish`.\
Pia inavutia kujua **umri wa kila domain ya mashaka uliyogundua**, kadri mdogo ndivyo hatari zaidi.\
Unaweza pia kupata **screenshots** za ukurasa wa HTTP na/au HTTPS wa tovuti yenye mashaka ili kuona ikiwa ni ya hovyo na katika hali hiyo **uingie ili ukaangalie kwa undani zaidi**.
### Ukaguzi wa Juu
Ikiwa unataka kwenda hatua moja mbele nakusihi **ufuatilie majina hayo ya kikoa yenye shaka na kutafuta zaidi** mara kwa mara (kila siku? inachukua sekunde/chache tu). Unapaswa pia **kuangalia** bandari **zilizofunguliwa** za IP zinazohusiana na **kutafuta mifano ya `gophish` au zana zinazofanana** (ndiyo, washambuliaji pia hufanya makosa) na **kufuatilia ukurasa wa wavuti wa HTTP na HTTPS wa majina ya kikoa yenye shaka na subdomains** ili kuona ikiwa wameiga fomu yoyote ya kuingia kutoka kwenye kurasa za wavuti za mwathirika.\
Ili **kujiandaa** kwa hili nakusihi uwe na orodha ya fomu za kuingia za majina ya kikoa ya mwathirika, spider ukurasa wa wavuti wenye shaka na kulinganisha kila fomu ya kuingia iliyopatikana ndani ya majina ya kikoa yenye shaka na kila fomu ya kuingia ya kikoa cha mwathirika kwa kutumia kitu kama `ssdeep`.\
Ikiwa umepata fomu za kuingia za majina ya kikoa yenye shaka, unaweza kujaribu **kutuma akidi za takataka** na **kuangalia ikiwa inakuhamisha kwenye kikoa cha mwathirika**.
Ikiwa ungependa kwenda hatua moja zaidi ningependekeza **kufuatilia domain hizo za mashaka na kutafuta zaidi** mara kwa mara (kila siku? huchukua sekunde/dakika chache tu). Pia unapaswa **kuangalia** ports zilizo wazi za IP zinazohusiana na **kutafuta instances za `gophish` au zana zinazofanana** (ndio, washambuliaji pia hufanya makosa) na **kuangalia HTTP na HTTPS wa kurasa za domain na subdomains zenye shaka** kuona kama wameiga fomu yoyote ya login kutoka kwenye kurasa za mwathiriwa.\
Ili **kuziweka otomatiki** ningependekeza kuwa na orodha ya fomu za login za domain za mwathiriwa, spider the suspicious web pages na kulinganisha kila fomu ya login iliyopatikana ndani ya domain zenye mashaka na kila fomu ya login ya domain ya mwathiriwa kwa kutumia kitu kama `ssdeep`.\
Kama umeweka fomu za login za domain zenye mashaka, unaweza kujaribu **kutuma nywila za junk** na **kuangalia kama inakurudisha kwenye domain ya mwathiriwa**.
## Majina ya kikoa yanayotumia maneno muhimu
---
Ukurasa wa mzazi pia unataja mbinu ya mabadiliko ya jina la kikoa ambayo inajumuisha kuweka **jina la kikoa la mwathirika ndani ya kikoa kikubwa** (kwa mfano, paypal-financial.com kwa paypal.com).
### Kufatilia kwa kutumia favicon na web fingerprints (Shodan/ZoomEye/Censys)
### Uwazi wa Cheti
Mifumo mingi ya phishing hutumia tena favicons kutoka kwa brand wanayoiga. Skana za mtandao wote huhesabu MurmurHash3 ya favicon iliyotangazwa kwa base64. Unaweza kuunda hash na kuifanya pivot:
Haiwezekani kuchukua mbinu ya awali ya "Brute-Force" lakini kwa kweli **inawezekana kufichua jaribio kama hilo la phishing** pia kwa shukrani kwa uwazi wa cheti. Kila wakati cheti kinapotolewa na CA, maelezo yanapatikana hadharani. Hii inamaanisha kwamba kwa kusoma uwazi wa cheti au hata kufuatilia, **inawezekana kupata majina ya kikoa yanayotumia neno muhimu ndani ya jina lake** Kwa mfano, ikiwa mshambuliaji anaunda cheti cha [https://paypal-financial.com](https://paypal-financial.com), kuona cheti kunawezekana kupata neno muhimu "paypal" na kujua kwamba barua pepe yenye shaka inatumika.
Mfano wa Python (mmh3):
```python
import base64, requests, mmh3
url = "https://www.paypal.com/favicon.ico" # change to your brand icon
b64 = base64.encodebytes(requests.get(url, timeout=10).content)
print(mmh3.hash(b64)) # e.g., 309020573
```
- Tafuta kwenye Shodan: `http.favicon.hash:309020573`
- Kwa kutumia tooling: angalia community tools kama favfreak ku-generate hashes na dorks kwa Shodan/ZoomEye/Censys.
Chapisho [https://0xpatrik.com/phishing-domains/](https://0xpatrik.com/phishing-domains/) linapendekeza kwamba unaweza kutumia Censys kutafuta vyeti vinavyoathiri neno muhimu maalum na kuchuja kwa tarehe (vyeti "vipya" pekee) na kwa mtoaji wa CA "Let's Encrypt":
Notes
- Favicons zinatumika tena; chukulia matches kama leads na validate content na certs kabla ya kuchukua hatua.
- Unganisha na domain-age na keyword heuristics kwa usahihi zaidi.
### Utafutaji wa telemetry za URL (urlscan.io)
`urlscan.io` inahifadhi historical screenshots, DOM, requests na TLS metadata za URL zilizotumwa. Unaweza kutafuta brand abuse na clones:
Example queries (UI or API):
- Tafuta lookalikes ukiondoa domain zako halali: `page.domain:(/.*yourbrand.*/ AND NOT yourbrand.com AND NOT www.yourbrand.com)`
- Tafuta sites zinazongeuka assets zako (hotlinking): `domain:yourbrand.com AND NOT page.domain:yourbrand.com`
- Punguza kwa matokeo ya karibuni: ongeza `AND date:>now-7d`
API example:
```bash
# Search recent scans mentioning your brand
curl -s 'https://urlscan.io/api/v1/search/?q=page.domain:(/.*yourbrand.*/%20AND%20NOT%20yourbrand.com)%20AND%20date:>now-7d' \
-H 'API-Key: <YOUR_URLSCAN_KEY>' | jq '.results[].page.url'
```
Kutoka kwenye JSON, zingatia:
- `page.tlsIssuer`, `page.tlsValidFrom`, `page.tlsAgeDays` ili kugundua vyeti vipya kabisa kwa matovuti yanayofanana
- `task.source` values like `certstream-suspicious` ili kuhusisha matokeo na ufuatiliaji wa CT
### Umri wa domain kupitia RDAP (inayoweza kuendeshwa kwa script)
RDAP hurudisha matukio ya uundaji yanayosomeka na mashine. Inafaa kuashiria **domain zilizosajiliwa hivi karibuni (NRDs)**.
```bash
# .com/.net RDAP (Verisign)
curl -s https://rdap.verisign.com/com/v1/domain/suspicious-example.com | \
jq -r '.events[] | select(.eventAction=="registration") | .eventDate'
# Generic helper using rdap.net redirector
curl -s https://www.rdap.net/domain/suspicious-example.com | jq
```
Boresheni pipeline yenu kwa ku-tag domains na makundi ya umri wa usajili (mf., <7 days, <30 days) na panga triage kwa kipaumbele ipasavyo.
### TLS/JAx fingerprints to spot AiTM infrastructure
Phishing za kisasa za credential mara nyingi zinatumia **Adversary-in-the-Middle (AiTM)** reverse proxies (mf., Evilginx) kuiba session tokens. Unaweza kuongeza utambuzi upande wa mtandao:
- Rekodi TLS/HTTP fingerprints (JA3/JA4/JA4S/JA4H) kwenye egress. Baadhi ya builds za Evilginx zimetazamwa zikiwa na JA4 client/server values thabiti. Toa tahadhari kwa fingerprints zinazojulikana-kutwa mbaya kama ishara dhaifu tu na thibitisha kila mara kwa content na domain intel.
- Rekodi kwa njia ya hiari metadata ya TLS certificate (issuer, SAN count, wildcard use, validity) kwa lookalike hosts zilizogunduliwa kupitia CT au urlscan na zilelekee/korelasha na umri wa DNS na geolocation.
> Kumbuka: Chukulia fingerprints kama uboreshaji, sio kama vikwazo pekee; frameworks hubadilika na zinaweza kubadilisha au kuficha taarifa.
### Domain names using keywords
Ukurasa mzazi pia unataja mbinu ya utofauti wa jina la domain inayojumuisha kuweka **jina la domain la mwathirika ndani ya domain kubwa** (mf., paypal-financial.com kwa paypal.com).
#### Certificate Transparency
Haiwezekani kutumia mbinu ya "Brute-Force" iliyotajwa hapo awali lakini kwa kweli **inawezekana kugundua jaribio kama hilo la phishing** pia shukrani kwa certificate transparency. Kila wakati CA inapotoa certificate, maelezo yake yanakuwa ya umma. Hii inamaanisha kwamba kwa kusoma certificate transparency au hata kuifuatilia, ni **inawezekana kupata domains zinazotumia neno muhimu ndani ya jina lao**. Kwa mfano, kama mshambuliaji anazalisha certificate ya [https://paypal-financial.com](https://paypal-financial.com), kwa kuona certificate inawezekana kupata neno muhimu "paypal" na kujua kwamba email inayoshukiwa inatumiwa.
Chapisho [https://0xpatrik.com/phishing-domains/](https://0xpatrik.com/phishing-domains/) kinapendekeza unaweza kutumia Censys kutafuta certificates zinazohusiana na neno maalum na kuchuja kwa tarehe (tu certificates "mpya") na kwa CA issuer "Let's Encrypt":
![https://0xpatrik.com/content/images/2018/07/cert_listing.png](<../../images/image (1115).png>)
Hata hivyo, unaweza kufanya "kile kile" kwa kutumia wavuti ya bure [**crt.sh**](https://crt.sh). Unaweza **kutafuta neno muhimu** na **kuchuja** matokeo **kwa tarehe na CA** ikiwa unataka.
Hata hivyo, unaweza kufanya "the same" ukitumia tovuti ya bure [**crt.sh**](https://crt.sh). Unaweza **kutafuta neno muhimu** na **kichuja** matokeo **kwa tarehe na CA** ikiwa unataka.
![](<../../images/image (519).png>)
Kwa kutumia chaguo hili la mwisho unaweza hata kutumia uwanja wa Matching Identities kuona ikiwa kuna kitambulisho chochote kutoka kwenye kikoa halisi kinacholingana na chochote cha majina ya kikoa yenye shaka (kumbuka kwamba jina la kikoa lenye shaka linaweza kuwa la uwongo).
Kwa kutumia chaguo la mwisho unaweza hata kutumia uwanja Matching Identities kuona kama identity yoyote kutoka domain halisi inaendana na yoyote ya domain zinazoshukiwa (kumbuka kwamba domain inayoshukiwa inaweza kuwa false positive).
**Chaguo lingine** ni mradi mzuri unaoitwa [**CertStream**](https://medium.com/cali-dog-security/introducing-certstream-3fc13bb98067). CertStream inatoa mtiririko wa wakati halisi wa vyeti vilivyoundwa hivi karibuni ambavyo unaweza kutumia kugundua maneno muhimu yaliyotajwa katika wakati (karibu) halisi. Kwa kweli, kuna mradi unaoitwa [**phishing_catcher**](https://github.com/x0rz/phishing_catcher) ambao unafanya hivyo.
**Another alternative** ni mradi mzuri uitwao [**CertStream**](https://medium.com/cali-dog-security/introducing-certstream-3fc13bb98067). CertStream hutoa mtiririko wa wakati-halisi wa certificates mpya zilizotengenezwa ambao unaweza kutumia kugundua maneno maalum kwa wakati (karibu) halisi. Kwa kweli, kuna mradi uitwao [**phishing_catcher**](https://github.com/x0rz/phishing_catcher) unaofanya hivyo.
### **Majina mapya ya kikoa**
Tip ya vitendo: unapotriage hits za CT, panga kipaumbele NRDs, registrars zisizo za kuaminika/zisizojulikana, privacy-proxy WHOIS, na certs zenye `NotBefore` za hivi karibuni. Dumisha allowlist ya domains/brand zako ili kupunguza kelele.
**Chaguo la mwisho** ni kukusanya orodha ya **majina mapya ya kikoa yaliyosajiliwa** kwa baadhi ya TLDs ([Whoxy](https://www.whoxy.com/newly-registered-domains/) inatoa huduma hiyo) na **kuangalia maneno muhimu katika majina haya ya kikoa**. Hata hivyo, majina marefu ya kikoa mara nyingi hutumia moja au zaidi ya subdomains, hivyo neno muhimu halitaonekana ndani ya FLD na huwezi kupata subdomain ya phishing.
#### **Domain mpya**
**Chaguo la mwisho** ni kukusanya orodha ya **domains zilizosajiliwa hivi karibuni** kwa baadhi ya TLDs ([Whoxy](https://www.whoxy.com/newly-registered-domains/) inatoa huduma hiyo) na **kukagua maneno muhimu katika domains hizi**. Hata hivyo, domains ndefu kwa kawaida hutumia subdomain moja au zaidi, hivyo neno muhimu hautaonekana ndani ya FLD na hautaweza kupata subdomain ya phishing.
Mchakato wa ziada: chukulia baadhi ya **file-extension TLDs** (mf., `.zip`, `.mov`) kwa tahadhari zaidi katika onyo. Hizi mara nyingi huchanganywa na majina ya faili katika lures; changanya ishara ya TLD na maneno ya brand na umri wa NRD kwa usahihi zaidi.
## Marejeo
- urlscan.io Search API reference: https://urlscan.io/docs/search/
- APNIC Blog JA4+ network fingerprinting (includes Evilginx example): https://blog.apnic.net/2023/11/22/ja4-network-fingerprinting/
{{#include ../../banners/hacktricks-training.md}}

View File

@ -24,13 +24,15 @@
/* 2 — load a single index (remote → local) */
async function loadIndex(remote, local, isCloud=false){
let rawLoaded = false;
try {
const r = await fetch(remote,{mode:'cors'});
if (!r.ok) throw new Error('HTTP '+r.status);
importScripts(URL.createObjectURL(new Blob([await r.text()],{type:'application/javascript'})));
rawLoaded = true;
} catch(e){ console.warn('remote',remote,'failed →',e); }
if(!rawLoaded){
if(remote){
try {
const r = await fetch(remote,{mode:'cors'});
if (!r.ok) throw new Error('HTTP '+r.status);
importScripts(URL.createObjectURL(new Blob([await r.text()],{type:'application/javascript'})));
rawLoaded = true;
} catch(e){ console.warn('remote',remote,'failed →',e); }
}
if(!rawLoaded && local){
try { importScripts(abs(local)); rawLoaded = true; }
catch(e){ console.error('local',local,'failed →',e); }
}
@ -40,13 +42,41 @@
return data;
}
async function loadWithFallback(remotes, local, isCloud=false){
if(remotes.length){
const [primary, ...secondary] = remotes;
const primaryData = await loadIndex(primary, null, isCloud);
if(primaryData) return primaryData;
if(local){
const localData = await loadIndex(null, local, isCloud);
if(localData) return localData;
}
for (const remote of secondary){
const data = await loadIndex(remote, null, isCloud);
if(data) return data;
}
}
return local ? loadIndex(null, local, isCloud) : null;
}
(async () => {
const MAIN_RAW = 'https://raw.githubusercontent.com/HackTricks-wiki/hacktricks/refs/heads/master/searchindex.js';
const CLOUD_RAW = 'https://raw.githubusercontent.com/HackTricks-wiki/hacktricks-cloud/refs/heads/master/searchindex.js';
const htmlLang = (document.documentElement.lang || 'en').toLowerCase();
const lang = htmlLang.split('-')[0];
const mainReleaseBase = 'https://github.com/HackTricks-wiki/hacktricks/releases/download';
const cloudReleaseBase = 'https://github.com/HackTricks-wiki/hacktricks-cloud/releases/download';
const mainTags = Array.from(new Set([`searchindex-${lang}`, 'searchindex-en', 'searchindex-master']));
const cloudTags = Array.from(new Set([`searchindex-${lang}`, 'searchindex-en', 'searchindex-master']));
const MAIN_REMOTE_SOURCES = mainTags.map(tag => `${mainReleaseBase}/${tag}/searchindex.js`);
const CLOUD_REMOTE_SOURCES = cloudTags.map(tag => `${cloudReleaseBase}/${tag}/searchindex.js`);
const indices = [];
const main = await loadIndex(MAIN_RAW , '/searchindex.js', false); if(main) indices.push(main);
const cloud= await loadIndex(CLOUD_RAW, '/searchindex-cloud.js', true ); if(cloud) indices.push(cloud);
const main = await loadWithFallback(MAIN_REMOTE_SOURCES , '/searchindex.js', false); if(main) indices.push(main);
const cloud= await loadWithFallback(CLOUD_REMOTE_SOURCES, '/searchindex-cloud.js', true ); if(cloud) indices.push(cloud);
if(!indices.length){ postMessage({ready:false, error:'no-index'}); return; }