mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-21 20:23:18 +00:00
commit
3a9ca37854
8 changed files with 8 additions and 8 deletions
|
@ -39,7 +39,7 @@ Imagine a server which is **signing** some **data** by **appending** a **secret*
|
|||
* Usually a default one is used, so if the other 3 requirements are met, this also is
|
||||
* The padding vary depending on the length of the secret+data, that's why the length of the secret is needed
|
||||
|
||||
Then, it's possible for an **attacker** to **append** **data** and **generate** a valid **signature** for the **previos data + appended data**.
|
||||
Then, it's possible for an **attacker** to **append** **data** and **generate** a valid **signature** for the **previous data + appended data**.
|
||||
|
||||
### How?
|
||||
|
||||
|
|
|
@ -26,7 +26,7 @@ Imagine a server which is **signing** some **data** by **appending** a **secret*
|
|||
* Usually a default one is used, so if the other 3 requirements are met, this also is
|
||||
* The padding vary depending on the length of the secret+data, that's why the length of the secret is needed
|
||||
|
||||
Then, it's possible for an **attacker** to **append** **data** and **generate** a valid **signature** for the **previos data + appended data**.
|
||||
Then, it's possible for an **attacker** to **append** **data** and **generate** a valid **signature** for the **previous data + appended data**.
|
||||
|
||||
## How?
|
||||
|
||||
|
|
|
@ -702,7 +702,7 @@ These items are stored in the file **`~/Library/Application Support/com.apple.ba
|
|||
|
||||
### ZIP as Login Item
|
||||
|
||||
(Check previos section about Login Items, this is an extension)
|
||||
(Check previous section about Login Items, this is an extension)
|
||||
|
||||
If you store a **ZIP** file as a **Login Item** the **`Archive Utility`** will open it and if the zip was for example stored in **`~/Library`** and contained the Folder **`LaunchAgents/file.plist`** with a backdoor, that folder will be created (it isn't by default) and the plist will be added so the next time the user logs in again, the **backdoor indicated in the plist will be executed**.
|
||||
|
||||
|
|
|
@ -522,7 +522,7 @@ gcc -framework Foundation -framework Appkit sc_inject.m -o sc_inject
|
|||
|
||||
### Dylib Injection in thread via Task port
|
||||
|
||||
In macOS **threads** might be manipulated via **Mach** or using **posix `pthread` api**. The thread we generated in the previos injection, was generated using Mach api, so **it's not posix compliant**.
|
||||
In macOS **threads** might be manipulated via **Mach** or using **posix `pthread` api**. The thread we generated in the previous injection, was generated using Mach api, so **it's not posix compliant**.
|
||||
|
||||
It was possible to **inject a simple shellcode** to execute a command because it **didn't need to work with posix** compliant apis, only with Mach. **More complex injections** would need the **thread** to be also **posix compliant**.
|
||||
|
||||
|
|
|
@ -818,7 +818,7 @@ For this to work on iOS you need the entitlement `dynamic-codesigning` in order
|
|||
|
||||
### Dylib Injection in thread via Task port
|
||||
|
||||
In macOS **threads** might be manipulated via **Mach** or using **posix `pthread` api**. The thread we generated in the previos injection, was generated using Mach api, so **it's not posix compliant**.
|
||||
In macOS **threads** might be manipulated via **Mach** or using **posix `pthread` api**. The thread we generated in the previous injection, was generated using Mach api, so **it's not posix compliant**.
|
||||
|
||||
It was possible to **inject a simple shellcode** to execute a command because it **didn't need to work with posix** compliant apis, only with Mach. **More complex injections** would need the **thread** to be also **posix compliant**.
|
||||
|
||||
|
|
|
@ -231,7 +231,7 @@ The scheme must be declarated in the **`AndroidManifest.xml`** file:
|
|||
[...]
|
||||
```
|
||||
|
||||
The scheme from the previos example is `exampleapp://` (note also the **`category BROWSABLE`**)
|
||||
The scheme from the previous example is `exampleapp://` (note also the **`category BROWSABLE`**)
|
||||
|
||||
Then, in the data field, you can specify the **host** and **path**:
|
||||
|
||||
|
|
|
@ -695,7 +695,7 @@ RETURNS (result TEXT);
|
|||
```
|
||||
|
||||
{% hint style="warning" %}
|
||||
Note that for the previos query to work **the function `dblink` needs to exist**. If it doesn't you could try to create it with
|
||||
Note that for the previous query to work **the function `dblink` needs to exist**. If it doesn't you could try to create it with
|
||||
|
||||
```sql
|
||||
CREATE EXTENSION dblink;
|
||||
|
|
|
@ -581,7 +581,7 @@ read = system,call,log,verbose,agent,user,config,dtmf,reporting,crd,diapla
|
|||
write = system,call,agent,user,config,command,reporting,originate
|
||||
```
|
||||
|
||||
* The previos profile is allowing **ANY IP address to connect** (if the password is known).
|
||||
* The previous profile is allowing **ANY IP address to connect** (if the password is known).
|
||||
* To **organize a call**, like specified previously, **no read permissions is necessary** and **only** **originate** in **write** is needed.
|
||||
|
||||
With those permissions any IP knowing the password could connect and extract too much info, like:
|
||||
|
|
Loading…
Reference in a new issue