Skip to content

Commit 775e362

Browse files
committed
site check
1 parent c99ce6c commit 775e362

File tree

85 files changed

+4417
-0
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

85 files changed

+4417
-0
lines changed
Lines changed: 9 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,9 @@
1+
---
2+
title: "Exploiting HP OpenView NNM - B.07.53"
3+
date: 2016-11-07 20:23:51 -0600
4+
categories: [windows_exploit_dev]
5+
tags: [zero_day, exploit_walkthrough] # TAG names should always be lowercase
6+
---
7+
8+
Site migration in process ..
9+
Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
---
2+
title: "Stack Canary Bypass"
3+
date: 2019-07-16 20:33:35 -0700
4+
categories: [linux_exploit_dev]
5+
tags: [exploit_walkthrough] # TAG names should always be lowercase
6+
---
7+
8+
Site migration in process ..
Lines changed: 67 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,67 @@
1+
---
2+
title: "Demystify a Java gadget chain to exploit insecure deserialization"
3+
date: 2019-11-24 12:19:45 -0800
4+
categories: [web_security]
5+
tags: [java, insecure_deserialization] # TAG names should always be lowercase
6+
---
7+
8+
Site migration in process .. Drafting notes..
9+
10+
11+
I was always curious about how the actual remote code execution occurs during the Insecure Deserialization process. So I thought of giving a try to understand the known harmful `gadgets` from `commons-collections-3.2.2.jar` and develop the entire chain from scratch.
12+
13+
We need to use `property oriented programming` to build a `RCE gadget` from the scratch.
14+
15+
## Component / Classes Used to build the gadget
16+
1. Default JRE System Libraries: HashMap
17+
2. `commons-collections-3.2.2.jar`:
18+
1. ChainedTransformer
19+
2. LazyMap
20+
3. TiedMapEntry
21+
4. HashBag
22+
23+
## 1. Command Execution using `Runtime` object directly
24+
We can use the Java `Runtime` object and its `exec()` method to execute any `system` commands.
25+
- for example, running the `mate-calculator` in linux.
26+
27+
![](image%202.png)
28+
29+
## 2. Command Execution using Reflection API and `Runtime` object
30+
* Java `Reflection API` is used to `examine` or `modify` the `behavior` of methods, classes, interfaces at `runtime`.
31+
- Through reflection API, we can invoke any method at `runtime` via `invoke()` function.
32+
- Here, we are trying to invoke `getRuntime()` method to get a `Runtime` object.
33+
34+
![](image.png)
35+
36+
## 3. Command Execution using `ConstantTransformer` and `InvokerTransformer` together
37+
38+
Before directly jump into the `Constant Transformer` and `InvokerTransformer`, first understand the `Transformer` class and the `transform()` method.
39+
40+
#### Transformer
41+
- It transforms an input object to an output object through `transform()` method.
42+
- It doesn’t change the input object.
43+
- It is mainly used for: `type conversion`, `extracting` parts of an object.
44+
45+
For example, we can create a class `MyReverse` by implementing the `Transformer`interface and `transform()` method.
46+
- Here, in `transform()` method, we specify how to reverse a `String` type object.
47+
48+
![](image%203.png)
49+
50+
When we call the `transform()` method via passing the argument of a `String` type object, it reverses the string.
51+
52+
![](image%204.png)
53+
54+
> The return type of the `transform()` method is `Object` therefore it can return any type of object.
55+
56+
### ConstantTransformer
57+
In contrast to the `Transformer` class, it always returns the `same object` that specified during `initialization`.
58+
59+
- If we Initialize a `ConstantTransformar` with `Runtime.class` and can call the `transform()` method with `any object`(for example, `HashSet`), we will always get the `Runtime.class` type object.
60+
61+
![](image%205.png)
62+
63+
### InvokerTransformer
64+
* During initialization, it takes a `method name` with optional parameters.
65+
* On `transform`, it calls that method for the object provided with the parameters.
66+
67+
![](image%206.png)
Lines changed: 131 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,131 @@
1+
---
2+
title: "Password Storage"
3+
date: 2024-09-28 08:17:55 -0800
4+
categories: [crypto]
5+
tags: [hashing] # TAG names should always be lowercase
6+
---
7+
8+
## Store password in clear text (insecure)
9+
10+
- If the attacker successfully compromises the database, they gain access to all passwords, allowing them to log in as any user.
11+
12+
## Store a password hash generated by common hashing algorithms(i.e. `md5`, `sha`) (insecure)
13+
14+
- If salt or randomness is not used, identical passwords will generate the same hash.
15+
- As a result, an attacker can deduce that two users have the same password simply by comparing their matching hashes.
16+
17+
## Store a `salted` hash generated by `fast` hashing algorithm (insecure)
18+
19+
- Here same password will generate two different hash outputs.
20+
- However, salt is public therefore building the rainbow table is still possible if used fast hashing algorithms like sha3, blake.
21+
22+
## Concept of Salt
23+
24+
1. The concept is similar to personalize a hash function with a key / secret to create an authenticated tag / message authentication code (MAC).
25+
2. However, salt is not a `secret` means
26+
1. We can store that in clear text. But it should not be accessible in public.
27+
2. We can store it in the same database but preferable separate table from password_hash.
28+
3. Salt should be generated from `CSRNG`(i.e `os.urandom()`) function.
29+
4. Salt should be unique per user. Thus, two passwords don't produce the same hash.
30+
5. Salt should be as long as the output of the hash, minimum `32 bytes`.
31+
1. If salt is too short, an attacker can again build the rainbow table for every possible salt.
32+
2. We cannot use `username` or `UID` as salt because they may not be generated by a CSRNG and may be too short to meet the minimum 32-byte requirement.
33+
6. Instead of simply appending or prepending the salt to the password, it’s recommended to use a proper hashing function that accepts the salt as a `dedicated parameter`.
34+
35+
### Is there any issue with prepending the salt to the password and using the SHA-2 algorithm?
36+
37+
- A **hash length extension attack** isn’t applicable here, since the attacker doesn’t need to compute a valid hash by guessing the salt length.
38+
- Instead, the attacker’s focus would be on recovering the original password from the known hash.
39+
- The main concern lies in the fact that SHA-2 is a fast hashing algorithm, making it easier for attackers to quickly generate rainbow tables.
40+
41+
42+
43+
### Is there any performance impact if we use slow hashing functions.
44+
45+
- Yes. this intentional slow down can have an impact on the performance of an application, especially during the authentication process when users are logging in and their passwords need to be hashed and compared against stored hashes.
46+
47+
- To mitigate the performance impact, many applications use techniques such as parallelism, multi-threading, or specialized hardware to help mitigate the slowdown caused by slow hashing algorithms.
48+
49+
- Additionally, using appropriate `work factor parameters `when configuring the hashing algorithm can allow you to strike a balance between security and performance.
50+
51+
## Concept of Pepper
52+
53+
1. A **pepper** is a `secret` added (`prepend` / `append`) to the password during hashing.
54+
2. This value should differs from a salt and that it is not stored alongside a password hash, but rather the pepper is kept separate in some other medium, such as a Hardware Security Module.
55+
3. NIST recommends size minimum 16 byte.
56+
4. It should be unique per application.
57+
5. Should be generated from `CSRNG` function.
58+
59+
60+
61+
## Password Hashing Algorithms
62+
63+
> 09/2024: All key derivation functions listed below are resistant to `rainbow table` attacks.
64+
{: .prompt-info }
65+
66+
1. PB-KDF2 - (Not Recommended anymore)
67+
68+
1. It is **NOT resistant** to
69+
1. GPU attacks (parallel password cracking using video cards) and to
70+
2. ASIC attacks (specialized password cracking hardware).
71+
2. Mostly known for using as KDF not password storage.
72+
3. Flexibility to specify the hashing algorithm as argument.
73+
74+
2. Bcrypt
75+
76+
1. **Less resistant** to ASIC and GPU attacks.
77+
2. Although it provides `configurable iterations count`, but uses `constant memory`,
78+
1. so it is easier to build `hardware-accelerated password crackers`.
79+
3. Salt is `pre-pended` with digest therefore it easily known by someone who has the hash.
80+
4. The bcrypt algorithm only handles passwords up to 72 characters, any characters beyond that are ignored.
81+
1. To work around this, a common approach is to hash a password with a cryptographic hash (such as sha256) and then base64 encode it to prevent NULL byte problems before hashing the result with bcrypt.
82+
5. It also can be used as KDF / key generation.
83+
84+
3. Scrypt - (Recommended)
85+
86+
1. It is `memory-intensive`, designed to prevent **GPU**, **ASIC** and **FPGA**(highly efficient password cracking hardware) based attacks.
87+
88+
2. Supports XOF.
89+
1. Cons: Cutdown version means shorter hash outputs are prefixes of longer hash outputs.
90+
91+
3. Function Arguments are
92+
93+
```text
94+
hash_key = Scrypt(password, salt, N, r, p, derived-key-len)
95+
96+
config parameters are:
97+
1. password => the input password (8-10 chars minimal length is recommended)
98+
2. salt => securely-generated random bytes (64 bits minimum, 128 bits recommended)
99+
3. p => parallelism factor (threads to run in parallel, affects the memory, CPU usage), e.g. 1
100+
4. n => iterations count (affects memory and CPU usage), e.g. 16384 or 2048, must be power of 2
101+
5. r => block size (affects memory and CPU usage), e.g. 8
102+
6. derived-key-length => how many bytes to generate as output, e.g. 32 bytes (256 bits)
103+
```
104+
105+
4. Argon2 - (Recommended)
106+
107+
1. Strong resistant to GPU, ASIC and FPGA attacks.
108+
2. Argon2 config parameters are very similar to Scrypt.
109+
3. API - `argon2_cffi` lib also provides function that supports inbuilt random salt generation.
110+
4. The Argon2 function has several variants:
111+
1. Argon2d – provides strong GPU resistance, but has potential side-channel attacks (possible in very special situations).
112+
2. Argon2i – provides less GPU resistance, but has no side-channel attacks.
113+
3. Argon2id – recommended (combines the Argon2d and Argon2i).
114+
115+
116+
## Summary: How to store and verify password
117+
118+
1. Use argon2 / scrypt.
119+
2. Use `pepper` along with the `salt` to add defense in depth.
120+
3. Avoid directly comparing two hashes as strings. If the application lacks rate limiting or CAPTCHA protection, it leaves the door open for attackers to execute a timing attack to guess the password.
121+
- Solution: XOR two hashes and compare with 0 or 1.
122+
- python3: Use compare_digest(good_sig, sig) method from `hmac` lib.
123+
124+
```python
125+
compare_result = hmac.compare_digest(str,str)
126+
```
127+
128+
129+
## Code Repo
130+
131+
https://github.com/greyshell/python_programming/tree/master/crypto/password_hashing
318 KB
Loading
336 KB
Loading
113 KB
Loading
302 KB
Loading
22.9 KB
Loading
352 KB
Loading

0 commit comments

Comments
 (0)