ch05 deel

main
Jef Roosens 2024-12-30 15:22:33 +01:00
parent fa117b6721
commit fe632b6ab5
No known key found for this signature in database
GPG Key ID: 69D2F0660E385613
3 changed files with 89 additions and 0 deletions

View File

@ -95,3 +95,92 @@
* ask target personnel for info on policy
* create test account for pentest
* attempt 1 password per observation window
## Password representation
* Windows
* Security Accounts Manager (SAM) for modern desktop versions
* stores all local account info
* login info from domain users that connected to the machine
* encrypted SAM database
* password hashes stored in registry
* LANMAN (LM) or NT hashes
* Active Directory newer alternative
### Lanman hash
* operation
1. truncate password to 14 characters (pad with NUL bytes if less)
2. convert to uppercase
3. split into two 7-char pieces
4. use each piece as 7-byte DES key to encrypt 64-bit known constant `KGS!@#$%`
5. hash is concatenation of two 8-byte outputs
* this hash is criminally bad
### NT hash
* operation
1. convert password (max 256 chars) into UTF-16 little endian format
2. hash using MD4 (no salt)
* better but still pretty bad
## Windows challenge-reponse authentication
* mutiple forms of network cryptographic authentication
* **LANMAN challenge/response**: legacy-only, uses LM hash
* **NTLMv1**: also legacy, uses NT hash
* **NTLMv2**: stronger security, uses NT hash
* **Microsoft Kerberos**
### LANMAN and NTLMv1
* operation
1. client initiates authentication
2. server sends 8-byte challenge
3. client formulates response
1. pad LM/NT hash to 21 bytes
2. split hash in three 7-byte pieces
3. use each piece as DES key to encrypt challenge
4. response is 3 8-byte outputs
4. server calculates same response and compares
* problems
* attacker can sniff both challenge and response and try to crack
* rogue server could issue static challenge for which it has rainbow tables
* works because neither hash uses salting
* without rogue server, method is slower than cracking hashes in SAM db
* no access to actual hash
* attacker needs to perform DES encryption
### NTLMv2
* operation
1. client sends authentication request
2. server sends 8-byte server challenge
3. client formulates response
1. creates NTLMv2 hash using HMAC-MD5
* data: username and domain name
* key: NT hash
2. creates NTLMv2 response using HMAC-MD5
* data: server challenge + data blob (client challenge, timestamp,
fields for integrity / security)
* key: NTLMv2 hash
4. client sends response to server
5. server computes validity of response using stored NT hash and received
fields
* cracking still possible but much slower
* stronger hash is used
* timestamp protects against replay attacks
* rainbow tables not useful due to variability of client challenge
### NTLM relay attacks
* both versions vulnerable
* possible if attacker can access server client usually uses
* ARP or DNS spoofing
* phishing
* cross-site scripting attacks
* operation
1. attacker poses as authentication server
2. attacker relays authentication request messages to real server -> acts
as authenticating client
3. attacker receives authentication and returns error message to client

Binary file not shown.

After

Width:  |  Height:  |  Size: 66 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 37 KiB