Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-15 09:27:32 +00:00
Code Issues Projects Releases Packages Wiki Activity

Delete crypto directory

Browse source
This commit is contained in:
Carlos Polop 2021-10-19 09:33:07 +01:00 committed by GitHub
parent bb1345bf9f
commit 6b1ea1a093
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
7 changed files with 0 additions and 897 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

176
crypto/certificates.md
View file

@ -1,176 +0,0 @@
# Certificates
## What is a Certificate
In cryptography, a **public key certificate,** also known as a **digital certificate** or **identity certificate,** is an electronic document used to prove the ownership of a public key. The certificate includes information about the key, information about the identity of its owner \(called the subject\), and the digital signature of an entity that has verified the certificate's contents \(called the issuer\). If the signature is valid, and the software examining the certificate trusts the issuer, then it can use that key to communicate securely with the certificate's subject.
In a typical [public-key infrastructure](https://en.wikipedia.org/wiki/Public-key_infrastructure) \(PKI\) scheme, the certificate issuer is a [certificate authority](https://en.wikipedia.org/wiki/Certificate_authority) \(CA\), usually a company that charges customers to issue certificates for them. By contrast, in a [web of trust](https://en.wikipedia.org/wiki/Web_of_trust) scheme, individuals sign each other's keys directly, in a format that performs a similar function to a public key certificate.
The most common format for public key certificates is defined by [X.509](https://en.wikipedia.org/wiki/X.509). Because X.509 is very general, the format is further constrained by profiles defined for certain use cases, such as [Public Key Infrastructure \(X.509\)](https://en.wikipedia.org/wiki/PKIX) as defined in RFC 5280.
## x509 Common Fields
* **Version Number:** Version of x509 format.
* **Serial Number**: Used to uniquely identify the certificate within a CA's systems. In particular this is used to track revocation information.
* **Subject**: The entity a certificate belongs to: a machine, an individual, or an organization.
* **Common Name**: Domains affected by the certificate. Can be 1 or more and can contain wildcards.
* **Country \(C\)**: Country
* **Distinguished name \(DN\)**: The whole subject: `C=US, ST=California, L=San Francisco, O=Example, Inc., CN=shared.global.example.net`
* **Locality \(L\)**: Local place
* **Organization \(O\)**: Organization name
* **Organizational Unit \(OU\)**: Division of an organisation \(like "Human Resources"\).
* **State or Province \(ST, S or P\)**: List of state or province names
* **Issuer**: The entity that verified the information and signed the certificate.
* **Common Name \(CN\)**: Name of the certificate authority
* **Country \(C\)**: Country of the certificate authority
* **Distinguished name \(DN\)**: Distinguished name of the certificate authority
* **Locality \(L\)**: Local place where the organisation can be found.
* **Organization \(O\)**: Organisation name
* **Organizational Unit \(OU\)**: Division of an organisation \(like "Human Resources"\).
* **Not Before**: The earliest time and date on which the certificate is valid. Usually set to a few hours or days prior to the moment the certificate was issued, to avoid [clock skew](https://en.wikipedia.org/wiki/Clock_skew#On_a_network) problems.
* **Not After**: The time and date past which the certificate is no longer valid.
* **Public Key**: A public key belonging to the certificate subject. \(This is one of the main parts as this is what is signed by the CA\)
* **Public Key Algorithm**: Algorithm used to generate the public key. Like RSA.
* **Public Key Curve**: The curve used by the elliptic curve public key algorithm \(if apply\). Like nistp521.
* **Public Key Exponent**: Exponent used to derive the public key \(if apply\). Like 65537.
* **Public Key Size**: The size of the public key space in bits. Like 2048.
* **Signature Algorithm**: The algorithm used to sign the public key certificate.
* **Signature**: A signature of the certificate body by the issuer's private key.
* **x509v3 extensions**
* **Key Usage**: The valid cryptographic uses of the certificate's public key. Common values include digital signature validation, key encipherment, and certificate signing.
* In a Web certificate this will appear as a _X509v3 extension_ and will have the value `Digital Signature`
* **Extended Key Usage**: The applications in which the certificate may be used. Common values include TLS server authentication, email protection, and code signing.
* In a Web certificate this will appear as a _X509v3 extension_ and will have the value `TLS Web Server Authentication`
* **Subject Alternative Name:** Allows users to specify additional host **names** for a single SSL **certificate**. The use of the SAN extension is standard practice for SSL certificates, and it's on its way to replacing the use of the common **name**.
* **Basic Constraint:** This extension describes whether the certificate is a CA certificate or an end entity certificate. A CA certificate is something that signs certificates of others and a end entity certificate is the certificate used in a web page for example \(the last par of the chain\).
* **Subject Key Identifier** \(SKI\): This extension declares a unique **identifier** for the public **key** in the certificate. It is required on all CA certificates. CAs propagate their own SKI to the Issuer **Key Identifier** \(AKI\) extension on issued certificates. It's the hash of the subject public key.
* **Authority Key Identifier**: It contains a key identifier which is derived from the public key in the issuer certificate. It's the hash of the issuer public key.
* **Authority Information Access** \(AIA\): This extension contains at most two types of information :
* Information about **how to get the issuer of this certificate** \(CA issuer access method\)
* Address of the **OCSP responder from where revocation of this certificate** can be checked \(OCSP access method\).
* **CRL Distribution Points**: This extension identifies the location of the CRL from which the revocation of this certificate can be checked. The application that processes the certificate can get the location of the CRL from this extension, download the CRL and then check the revocation of this certificate.
* **CT Precertificate SCTs**: Logs of Certificate transparency regarding the certificate
### Difference between OSCP and CRL Distribution Points
**OCSP** \(RFC 2560\) is a standard protocol that consists of an **OCSP client and an OCSP responder**. This protocol **determines revocation status of a given digital public-key certificate** **without** having to **download** the **entire CRL**.
**CRL** is the **traditional method** of checking certificate validity. A **CRL provides a list of certificate serial numbers** that have been revoked or are no longer valid. CRLs let the verifier check the revocation status of the presented certificate while verifying it. CRLs are limited to 512 entries.
From [here](https://www.arubanetworks.com/techdocs/ArubaOS%206_3_1_Web_Help/Content/ArubaFrameStyles/CertRevocation/About_OCSP_and_CRL.htm#:~:text=OCSP%20%28RFC%202560%29%20is%20a,to%20download%20the%20entire%20CRL.&text=A%20CRL%20provides%20a%20list,or%20are%20no%20longer%20valid.).
### What is Certificate Transparency
Certificate Transparency aims to remedy certificate-based threats by **making the issuance and existence of SSL certificates open to scrutiny by domain owners, CAs, and domain users**. Specifically, Certificate Transparency has three main goals:
* Make it impossible \(or at least very difficult\) for a CA to **issue a SSL certificate for a domain without the certificate being visible to the owner** of that domain.
* Provide an **open auditing and monitoring system that lets any domain owner or CA determine whether certificates have been mistakenly or maliciously** issued.
* **Protect users** \(as much as possible\) from being duped by certificates that were mistakenly or maliciously issued.
#### **Certificate Logs**
Certificate logs are simple network services that maintain **cryptographically assured, publicly auditable, append-only records of certificates**. **Anyone can submit certificates to a log**, although certificate authorities will likely be the foremost submitters. Likewise, anyone can query a log for a cryptographic proof, which can be used to verify that the log is behaving properly or verify that a particular certificate has been logged. The number of log servers doesn’t have to be large \(say, much less than a thousand worldwide\), and each could be operated independently by a CA, an ISP, or any other interested party.
#### Query
You can query the logs of Certificate Transparency of any domain in [https://crt.sh/](https://crt.sh/).
## Formats
There are different formats that can be used to store a certificate.
#### **PEM Format**
* It is the most common format used for certificates
* Most servers \(Ex: Apache\) expects the certificates and private key to be in a separate files - Usually they are Base64 encoded ASCII files - Extensions used for PEM certificates are .cer, .crt, .pem, .key files - Apache and similar server uses PEM format certificates
#### **DER Format**
* The DER format is the binary form of the certificate
* All types of certificates & private keys can be encoded in DER format
* DER formatted certificates do not contain the "BEGIN CERTIFICATE/END CERTIFICATE" statements
* DER formatted certificates most often use the ‘.cer’ and '.der' extensions
* DER is typically used in Java Platforms
#### **P7B/PKCS\#7 Format**
* The PKCS\#7 or P7B format is stored in Base64 ASCII format and has a file extension of .p7b or .p7c
* A P7B file only contains certificates and chain certificates \(Intermediate CAs\), not the private key
* The most common platforms that support P7B files are Microsoft Windows and Java Tomcat
#### **PFX/P12/PKCS\#12 Format**
* The PKCS\#12 or PFX/P12 format is a binary format for storing the server certificate, intermediate certificates, and the private key in one encryptable file
* These files usually have extensions such as .pfx and .p12
* They are typically used on Windows machines to import and export certificates and private keys
### Formats conversions
**Convert x509 to PEM**
```text
openssl x509 -in certificatename.cer -outform PEM -out certificatename.pem
```
#### **Convert PEM to DER**
```text
openssl x509 -outform der -in certificatename.pem -out certificatename.der
```
**Convert DER to PEM**
```text
openssl x509 -inform der -in certificatename.der -out certificatename.pem
```
**Convert PEM to P7B**
**Note:** The PKCS\#7 or P7B format is stored in Base64 ASCII format and has a file extension of .p7b or .p7c. ****A P7B file only contains certificates and chain certificates \(Intermediate CAs\), not the private key. The most common platforms that support P7B files are Microsoft Windows and Java Tomcat.
```text
openssl crl2pkcs7 -nocrl -certfile certificatename.pem -out certificatename.p7b -certfile CACert.cer
```
**Convert PKCS7 to PEM**
```text
openssl pkcs7 -print_certs -in certificatename.p7b -out certificatename.pem
```
**Convert pfx to PEM**
**Note:** The PKCS\#12 or PFX format is a binary format for storing the server certificate, intermediate certificates, and the private key in one encryptable file. PFX files usually have extensions such as .pfx and .p12. PFX files are typically used on Windows machines to import and export certificates and private keys.
```text
openssl pkcs12 -in certificatename.pfx -out certificatename.pem
```
**Convert PFX to PKCS\#8**
**Note:** This requires 2 commands
**1- Convert PFX to PEM**
```text
openssl pkcs12 -in certificatename.pfx -nocerts -nodes -out certificatename.pem
```
**2- Convert PEM to PKCS8**
```text
openSSL pkcs8 -in certificatename.pem -topk8 -nocrypt -out certificatename.pk8
```
**Convert P7B to PFX**
**Note:** This requires 2 commands
1- **Convert P7B to CER**
```text
openssl pkcs7 -print_certs -in certificatename.p7b -out certificatename.cer
```
**2- Convert CER and Private Key to PFX**
```text
openssl pkcs12 -export -in certificatename.cer -inkey privateKey.key -out certificatename.pfx -certfile cacert.cer
```

65
crypto/cipher-block-chaining-cbc-mac-priv.md
View file

@ -1,65 +0,0 @@
---
description: 'https://pentesterlab.com/'
---
# Cipher Block Chaining CBC-MAC
**Post from** [**https://pentesterlab.com/**](https://pentesterlab.com/)\*\*\*\*
## CBC
The easiest attack to test is that if the cookie just the username encrypted.
If the cookie is only the username \(or the first part of the cookie is the username\) and you want to impersonate the username "**admin**". Then, you can create the username **"bdmin"** and bruteforce the first byte of the cookie.
## CBC-MAC
CBC-MAC is a method to ensure integrity of a message by encrypting it using CBC mode and keeping the last encrypted block as "signature". This ensures that a malicious user can not modify any part of the data without having to change the signature. The key used for the "encryption" ensures that the signature can't be guessed.
However, when using CBC-MAC, the developer needs to be very careful if the message are not of fixed length. In this example, we will use the fact that there is no protection in place to get the application to sign two messages and build another message by concatenating the two messages.
## Theory
With CBC-MAC, we can generate two signatures `t` and `t'` for the messages `m` and `m'`. By using `m` and `m'` we can forge another message `m''` that will have the same signature as `m'` \(`t'`\). One thing to keep in mind is that the recommended way to use CBC-MAC is to use a NULL IV.
To keep things simple, we are going to work on a single block for each message.
We can see below how signing both messages works \(NB: both signatures are completely independent from each other\):
![](https://pentesterlab.com/cbc-mac/cbc-mac-1.png)
If we try to concatenate those messages, the signature is no longer valid \(since `t` is now the IV for the second block where it was only NULL before\):
![](https://pentesterlab.com/cbc-mac/cbc-mac-2.png)
However, if we XOR `m'` and `t`, the signature is now `t'`:
![](https://pentesterlab.com/cbc-mac/cbc-mac-3.png)
## Implementation
Based on the size of the signature, we can guess that the block size is likely to be 8. With this information, we will split `administrator`:
* `administ`
* `rator\00\00\00`
We can trivially generate the signature for the first block, by just logging in and retrieving the signature `t`.
For the second block, we want the `m'` XOR `t` to be equal to `rator\00\00\00`. So to generate the second username we will need to XOR `rator\00\00\00` with `t` \(since the application will sign it with a NULL IV instead of `t`\). Once we have this value, we can get the signature `t'`.
Finally, we just need to concatenate `m` and `m'` to get `administrator` and use `t'` as signature.
#### Resume
1. Get the signature of username **administ** = **t**
2. Get the signature of username **rator\x00\x00\x00 XOR t** = **t'**
3. Set in the cookie the value **administrator+t'** \(**t'** will be a valid signature of **\(rator\x00\x00\x00 XOR t\) XOR t** = **rator\x00\x00\x00**
### CBC-MAC simple attack \(controlling IV\)
If you can control the used IV the attack could be very easy.
To impersonate the user "**administrator**" you can create the user "**Administrator**" and you will have the cookie with the **username+signature** and the cookie with the **IV**.
To generate the cookies of the username "**administrator**" change the first cookie and set the username from "**Administrator**" to "**administrator**". Change the first byte of the cookie of the **IV** so **IV\[0\] XOR "A" == IV'\[0\] XOR "a"**. Using these cookies you can login as administrator.

256
crypto/crypto-ctfs-tricks.md
View file

@ -1,256 +0,0 @@
# Crypto CTFs Tricks
## Online Hashes DBs
* _**Google it**_
* [http://hashtoolkit.com/reverse-hash?hash=4d186321c1a7f0f354b297e8914ab240](http://hashtoolkit.com/reverse-hash?hash=4d186321c1a7f0f354b297e8914ab240)
* [https://www.onlinehashcrack.com/](https://www.onlinehashcrack.com/)
* [https://crackstation.net/](https://crackstation.net/)
* [https://md5decrypt.net/](https://md5decrypt.net/)
* [https://www.onlinehashcrack.com](https://www.onlinehashcrack.com)
* [https://gpuhash.me/](https://gpuhash.me/)
* [https://hashes.org/search.php](https://hashes.org/search.php)
* [https://www.cmd5.org/](https://www.cmd5.org/)
* [https://hashkiller.co.uk/Cracker/MD5](https://hashkiller.co.uk/Cracker/MD5)
* [https://www.md5online.org/md5-decrypt.html](https://www.md5online.org/md5-decrypt.html)
## Encoders
Most of encoded data can be decoded with these 2 ressources:
* [https://www.dcode.fr/tools-list](https://www.dcode.fr/tools-list)
* [https://gchq.github.io/CyberChef/](https://gchq.github.io/CyberChef/)
### Substitution Autosolvers
* [https://www.boxentriq.com/code-breaking/cryptogram](https://www.boxentriq.com/code-breaking/cryptogram)
* [https://quipqiup.com/](https://quipqiup.com/) - Very good !
#### Caesar - ROTx Autosolvers
* [https://www.nayuki.io/page/automatic-caesar-cipher-breaker-javascript](https://www.nayuki.io/page/automatic-caesar-cipher-breaker-javascript)
#### Atbash Cipher
* [http://rumkin.com/tools/cipher/atbash.php](http://rumkin.com/tools/cipher/atbash.php)
### Similar to BASE64
Check all bases with: [https://github.com/mufeedvh/basecrack](https://github.com/mufeedvh/basecrack)
* **Base32** \[_A-Z2-7=_\]
* `NBXWYYLDMFZGCY3PNRQQ====`
* **Base58** \[_123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz_\]
* `2yJiRg5BF9gmsU6AC`
* **Base62** \[_0-9A-Za-z_\]
* `g2AextRZpBKRBzQ9`
* **Base64** \[_A-Za-z0-9+/=_\]
* `aG9sYWNhcmFjb2xh`
* **Base85 --> Like Ascii85**
* **ATOM-128** \[_/128GhIoPQROSTeUbADfgHijKLM+n0pFWXY456xyzB7=39VaqrstJklmNuZvwcdEC_\]
* `MIc3KiXa+Ihz+lrXMIc3KbCC`
* **HAZZ15** \[_HNO4klm6ij9n+J2hyf0gzA8uvwDEq3X1Q7ZKeFrWcVTts/MRGYbdxSo=ILaUpPBC5_\]
* `DmPsv8J7qrlKEoY7`
* **MEGAN35** \[_3GHIJKLMNOPQRSTUb=cdefghijklmnopWXYZ/12+406789VaqrstuvwxyzABCDEF5_\]
* `kLD8iwKsigSalLJ5`
* **ZONG22** \[_ZKj9n+yf0wDVX1s/5YbdxSo=ILaUpPBCHg8uvNO4klm6iJGhQ7eFrWczAMEq3RTt2_\]
* `ayRiIo1gpO+uUc7g`
* **ESAB46** \[\]
* `3sHcL2NR8WrT7mhR`
* **MEGAN45** \[\]
* `kLD8igSXm2KZlwrX`
* **TIGO3FX** \[\]
* `7AP9mIzdmltYmIP9mWXX`
* **TRIPO5** \[\]
* `UE9vSbnBW6psVzxB`
* **FERON74** \[\]
* `PbGkNudxCzaKBm0x`
* **GILA7** \[\]
* `D+nkv8C1qIKMErY1`
* **Citrix CTX1** \[\]
* `MNGIKCAHMOGLKPAKMMGJKNAINPHKLOBLNNHILCBHNOHLLPBK`
[http://k4.cba.pl/dw/crypo/tools/eng\_atom128c.html](http://k4.cba.pl/dw/crypo/tools/eng_atom128c.html) - 404 Dead: [https://web.archive.org/web/20190228181208/http://k4.cba.pl/dw/crypo/tools/eng\_hackerize.html](https://web.archive.org/web/20190228181208/http://k4.cba.pl/dw/crypo/tools/eng_hackerize.html)
### HackerizeXS \[_╫Λ↻├☰┏_\]
```text
╫☐↑Λ↻Λ┏Λ↻☐↑Λ
```
* [http://k4.cba.pl/dw/crypo/tools/eng\_hackerize.html](http://k4.cba.pl/dw/crypo/tools/eng_hackerize.html) - 404 Dead: [https://web.archive.org/web/20190228181208/http://k4.cba.pl/dw/crypo/tools/eng\_hackerize.html](https://web.archive.org/web/20190228181208/http://k4.cba.pl/dw/crypo/tools/eng_hackerize.html)
### Morse
```text
.... --- .-.. -.-. .- .-. .- -.-. --- .-.. .-
```
* [http://k4.cba.pl/dw/crypo/tools/eng\_morse-encode.html](http://k4.cba.pl/dw/crypo/tools/eng_morse-encode.html) - 404 Dead: [https://gchq.github.io/CyberChef/](https://gchq.github.io/CyberChef/)
### UUencoder
```text
begin 644 webutils_pl
M2$],04A/3$%(3TQ!2$],04A/3$%(3TQ!2$],04A/3$%(3TQ!2$],04A/3$%(
M3TQ!2$],04A/3$%(3TQ!2$],04A/3$%(3TQ!2$],04A/3$%(3TQ!2$],04A/
F3$%(3TQ!2$],04A/3$%(3TQ!2$],04A/3$%(3TQ!2$],04A/3$$`
`
end
```
* [http://www.webutils.pl/index.php?idx=uu](http://www.webutils.pl/index.php?idx=uu)
### XXEncoder
```text
begin 644 webutils_pl
hG2xAEIVDH236Hol-G2xAEIVDH236Hol-G2xAEIVDH236Hol-G2xAEIVDH236
5Hol-G2xAEE++
end
```
* [www.webutils.pl/index.php?idx=xx](https://github.com/carlospolop/hacktricks/tree/bf578e4c5a955b4f6cdbe67eb4a543e16a3f848d/crypto/www.webutils.pl/index.php?idx=xx)
### YEncoder
```text
=ybegin line=128 size=28 name=webutils_pl
ryvkryvkryvkryvkryvkryvkryvk
=yend size=28 crc32=35834c86
```
* [http://www.webutils.pl/index.php?idx=yenc](http://www.webutils.pl/index.php?idx=yenc)
### BinHex
```text
(This file must be converted with BinHex 4.0)
:#hGPBR9dD@acAh"X!$mr2cmr2cmr!!!!!!!8!!!!!-ka5%p-38K26%&)6da"5%p
-38K26%'d9J!!:
```
* [http://www.webutils.pl/index.php?idx=binhex](http://www.webutils.pl/index.php?idx=binhex)
### ASCII85
```text
<~85DoF85DoF85DoF85DoF85DoF85DoF~>
```
* [http://www.webutils.pl/index.php?idx=ascii85](http://www.webutils.pl/index.php?idx=ascii85)
### Dvorak keyboard
```text
drnajapajrna
```
* [https://www.geocachingtoolbox.com/index.php?lang=en&page=dvorakKeyboard](https://www.geocachingtoolbox.com/index.php?lang=en&page=dvorakKeyboard)
### A1Z26
Letters to their numerical value
```text
8 15 12 1 3 1 18 1 3 15 12 1
```
### Affine Cipher Encode
Letter to num `(ax+b)%26` \(_a_ and _b_ are the keys and _x_ is the letter\) and the result back to letter
```text
krodfdudfrod
```
### SMS Code
**Multitap** [replaces a letter](https://www.dcode.fr/word-letter-change) by repeated digits defined by the corresponding key code on a mobile [phone keypad](https://www.dcode.fr/phone-keypad-cipher) \(This mode is used when writing SMS\).
For example: 2=A, 22=B, 222=C, 3=D...
You can identify this code because you will see **several numbers repeated**.
You can decode this code in: [https://www.dcode.fr/multitap-abc-cipher](https://www.dcode.fr/multitap-abc-cipher)
### Bacon Code
Substitude each letter for 4 As or Bs \(or 1s and 0s\)
```text
00111 01101 01010 00000 00010 00000 10000 00000 00010 01101 01010 00000
AABBB ABBAB ABABA AAAAA AAABA AAAAA BAAAA AAAAA AAABA ABBAB ABABA AAAAA
```
### Runes
![](../.gitbook/assets/runes.jpg)
## Compression
**Raw Deflate** and **Raw Inflate** \(you can find both in Cyberchef\) can compress and decompress data without headers.
## Easy Crypto
### XOR - Autosolver
* [https://wiremask.eu/tools/xor-cracker/](https://wiremask.eu/tools/xor-cracker/)
### Bifid
A keywork is needed
```text
fgaargaamnlunesuneoa
```
### Vigenere
A keywork is needed
```text
wodsyoidrods
```
* [https://www.guballa.de/vigenere-solver](https://www.guballa.de/vigenere-solver)
* [https://www.dcode.fr/vigenere-cipher](https://www.dcode.fr/vigenere-cipher)
* [https://www.mygeocachingprofile.com/codebreaker.vigenerecipher.aspx](https://www.mygeocachingprofile.com/codebreaker.vigenerecipher.aspx)
## Strong Crypto
### Fernet
2 base64 strings \(token and key\)
```text
Token:
gAAAAABWC9P7-9RsxTz_dwxh9-O2VUB7Ih8UCQL1_Zk4suxnkCvb26Ie4i8HSUJ4caHZuiNtjLl3qfmCv_fS3_VpjL7HxCz7_Q==
Key:
-s6eI5hyNh8liH7Gq0urPC-vzPgNnxauKvRO4g03oYI=
```
* [https://asecuritysite.com/encryption/ferdecode](https://asecuritysite.com/encryption/ferdecode)
### Samir Secret Sharing
A secret is splitted in X parts and to recover it you need Y parts \(_Y &lt;=X_\).
```text
8019f8fa5879aa3e07858d08308dc1a8b45
80223035713295bddf0b0bd1b10a5340b89
803bc8cf294b3f83d88e86d9818792e80cd
```
[http://christian.gen.co/secrets/](http://christian.gen.co/secrets/)
### OpenSSL brute-force
* [https://github.com/glv2/bruteforce-salted-openssl](https://github.com/glv2/bruteforce-salted-openssl)
* [https://github.com/carlospolop/easy\_BFopensslCTF](https://github.com/carlospolop/easy_BFopensslCTF)
## Tools
* [https://github.com/Ganapati/RsaCtfTool](https://github.com/Ganapati/RsaCtfTool)
* [https://github.com/lockedbyte/cryptovenom](https://github.com/lockedbyte/cryptovenom)
* [https://github.com/nccgroup/featherduster](https://github.com/nccgroup/featherduster)

226
crypto/electronic-code-book-ecb.md
View file

@ -1,226 +0,0 @@
---
description: 'https://pentesterlab.com/'
---
# Electronic Code Book \(ECB\)
**Post from:** [**https://pentesterlab.com/**](https://pentesterlab.com/)\*\*\*\*
## ECB
ECB is an encryption mode in which the message is splitted into blocks of X bytes length and each block is encrypted separetely using a key.
The following schema \(source: [Wikipedia](http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation)\) explains this method:
![License](https://assets.pentesterlab.com/ecb/ECB_encryption.png)
You can check the [recent XKCD on the Adobe's password leak](http://xkcd.com/1286/) to get an humoristic idea of the problems tied to ECB.
During the decryption, the reverse operation is used. Using ECB has multiple security implications:
* Blocks from encrypted message can be removed without disturbing the decryption process.
* Blocks from encrypted message can be moved around without disturbing the decryption process.
In this exercise, we will see how we can exploit these two weaknesses.
## Detection of the vulnerability
In this exercise, you can register an account and log in with this account \(to make things easier, you get automatically logged in when you register\).
If you create an account and log in two times with this account, you can see that the cookie sent by the application didn't change.If you log in many times and always get the same cookie, there is probably something wrong in the application. The cookie sent back should be unique each time you log in. If the cookie is always the same, it will probably always be valid and there won't be anyway to invalidate it.
If we look at the cookie, we can see that it seems uri-encoded and base64-encoded:
![License](https://assets.pentesterlab.com/ecb/cookie.png)
The 2 equals sign encoded as `%3d%3d` are a good indicator of base64-encoded string.
We can decode it using the following ruby code:
```text
% irb
> require 'base64' ; require 'uri'
=> true
> Base64.decode64(URI.decode("OR9hcp18%2BC1bChK10NlRRg%3d%3d"))
=> "9\x1Far\x9D|\xF8-[\n\x12\xB5\xD0\xD9QF"
```
Or by decoding the URI to a string manually and use the base64 command:
```text
% echo "OR9hcp18+C1bChK10NlRRg==" | base64 -D | hexdump -C
0000000 39 1f 61 72 9d 7c f8 2d 5b 0a 12 b5 d0 d9 51 46 |9.ar.|.-[.....QF|
0000010
```
On osX, the command `base64 -D` replaces `base64 -d`
In both cases, we can see that the information seems to be encrypted.
First, we can start by creating two accounts `test1` and `test2` with the same password: `password` and compare the cookies sent by the application. We get the following cookies \(after URI-decoding\):
| Account: | test1 | test2 |
| :--- | :--- | :--- |
| Cookie: | vHMQ+Nq9C3MHT8ZkGeMr4w== | Mh+JMH1OMhcHT8ZkGeMr4w== |
If we base64-decode both cookies, we get the following strings:
| Account: | test1 | test2 |
| :--- | :--- | :--- |
| Decoded cookie: | \xBCs\x10\xF8\xDA\xBD\vs**\aO\xC6d\x19\xE3+\xE3** | 2\x1F\x890}N2\x17**\aO\xC6d\x19\xE3+\xE3** |
We can see that part of the decrypted values look really similar.
Now we can try to create a user with an arbitrary long username and password. For example, a username composed of 20 `a` and a password composed of 20 `a`. By creating this user, we get the following cookie:
```text
> document.cookie
"auth=GkzSM2vKHdcaTNIza8od1wS28inRHiC2GkzSM2vKHdcaTNIza8od1ys96EXmirn5"
```
If we decode this value, we get the following value:
```text
\x1AL\xD23k\xCA\x1D\xD7\x1AL\xD23k\xCA\x1D\xD7\x04\xB6\xF2)\xD1\x1E \xB6\x1AL\xD23k\xCA\x1D\xD7\x1AL\xD23k\xCA\x1D\xD7+=\xE8E\xE6\x8A\xB9\xF9
```
We can see that the following pattern \(composed of 8 bytes\): **`\x1AL\xD23k\xCA\x1D\xD7`** comes back multiple times:
```text
\x1AL\xD23k\xCA\x1D\xD7\x1AL\xD23k\xCA\x1D\xD7\x04\xB6\xF2)\xD1\x1E \xB6\x1AL\xD23k\xCA\x1D\xD7\x1AL\xD23k\xCA\x1D\xD7+=\xE8E\xE6\x8A\xB9\xF9
```
Based on the size of the pattern, we can infer that the ECB encryption uses a block size of 8 bytes.This example is using a weak encryption mechanism and it's likely that real life examples will use bigger block size.
The decoded information also shows us that the username and password are not directly concatenated and that a delimiter is added \(since one of the block in the middle is different from the previous one\).
We can think of the encrypted stream has one of the two following possibilities:
* The stream contains the username, a delimiter and the password:
![Schema username password](https://assets.pentesterlab.com/ecb/del_u_p.png)
* The stream contains the password, a delimiter and the username:
![Schema password username](https://assets.pentesterlab.com/ecb/del_p_u.png)
By creating another user with a long username and a short password, we can see that the following pattern is used: `username|delimiter|password`.
Now let's try to find the size of the delimiter, if we play with different size of username and password we get the following results:
| Username length: | Password length: | Username+Password length: | Cookie's length \(after decoding\): |
| :--- | :--- | :--- | :--- |
| 2 | 3 | 5 | 8 |
| 3 | 3 | 6 | 8 |
| 3 | 4 | 7 | 8 |
| 4 | 4 | 8 | 16 |
| 4 | 5 | 9 | 16 |
We can see that the size of the decoded cookie goes from 8 to 16 bytes when the length of the Username+Password is greater than 7. We can infer from this value that the delimiter is a single byte since the encryption is done per block of 8 bytes.
Another important thing is to see what part of the encrypted stream is used by the application when we send the cookie back. If we remove everything after the block corresponding to the delimiter, we can see that we are still authenticated. The password does not seem to be used when the cookie gets used by the application.
We now know that we just need to get the correct `username|delimiter` to get authenticated within the application as `username`.If you can find what delimiter is used \(or brute force it\), you can try to create a user with a username that contains the delimiter \(for example the username "`admin:`"\). Using this method, you may be able to get logged in as `admin`. This web application prevents this type of attack.
## Exploitation of the vulnerability
### By removing information
The easiest way to get `admin` access is to remove some of the encrypted data. We know that the application uses the following format:
```text
\[username\]:\[separator\]
```
and only uses the `username` when the cookie is sent back to the application. We also know that each block of 8 bytes is completely independant \(ECB\). To exploit this issue, we can create a username that contains 8 characters followed by the word `admin`:
```text
aaaaaaaaadmin
```
And we will receive the cookie \(retrieved using the Javascript Console\):
```text
> document.cookie
"auth=GkzSM2vKHdfgVmQuKXLregdPxmQZ4yvj"
```
This value will get decoded as:
```text
\x1AL\xD23k\xCA\x1D\xD7\xE0Vd.)r\xEBz\aO\xC6d\x19\xE3+\xE3
```
We can see the pattern `\x1AL\xD23k\xCA\x1D\xD7` detected previously with the username that contained 20 `a`.
We can then remove the first 8 bytes of information and reencode our payload to get a new cookie:
```text
\xE0Vd.)r\xEBz\aO\xC6d\x19\xE3+\xE3
```
That will get encoded by the following ruby code:
```text
% irb
> require 'cgi'; require 'base64'
=> true
> CGI.escape(Base64.strict_encode64("\xE0Vd.)r\xEBz\aO\xC6d\x19\xE3+\xE3"))
=> "4FZkLily63oHT8ZkGeMr4w%3D%3D"
```
Once you modify the cookie:
![Cookie tampering with JS console](https://assets.pentesterlab.com/ecb/cookiemod.png)
And send this value back to the application \(by reloading the page\), you get logged in as `admin`:
![License](https://assets.pentesterlab.com/ecb/admin.png)
### By swapping blocks around
A more complicated way to bypass this is to swap data around. We can make the assumption that the application will use an SQL query to retrieve information from the user based on his `username`. For some databases, when using the type of data `VARCHAR` \(as opposed to `BINARY` for example\), the following will give the same result:
```text
SELECT * FROM users WHERE username='admin';
```
```text
SELECT * FROM users WHERE username='admin ';
```
The spaces after the value `admin` are ignored during the string comparison. We will use this to play with the encrypted blocks.
Our goal is to end up with the following encrypted data:
```text
ECB(admin [separator]password)
```
We know that our separator is only composed of one byte. We can use this information to create the perfect `username` and `password`to be able to swap the blocks and get the correct forged value.
We need to find a username and a password for which:
* the password starts with `admin` to be used as the new username.
* the encrypted password should be located at the start of a new block.
* the `username+delimiter` length should be divisible by the block size \(from previous conditions\)
By playing around, we can see that the following values work:
* a `username` composed of `password` \(8 bytes\) followed by 7 spaces \(1 byte will be used by the delimiter\).
* a `password` composed of `admin` followed by 3 spaces \(`8 - length("admin")`\).
When creating this user, use a proxy to intercept the request and make sure your browser didn't remove the space characters.
If you create correctly this user, the encrypted information will look like:![License](https://assets.pentesterlab.com/ecb/swap-b.png)
Using some Ruby \(or even with Burp decoder\), you can swap the first 8 bytes with the last 8 bytes to get the following encrypted stream:![License](https://assets.pentesterlab.com/ecb/swap-a.png)
Once you modify your cookie, and you reload the page, you should be logged in as `admin`:
![License](https://assets.pentesterlab.com/ecb/admin.png)
## Conclusion
This exercise showed you how you can tamper encrypted information without decrypting them and use this behaviour to gain access to other accounts. It showed you that encryption can not be used as a replacement to signature and how it's possible to use ECB encryption to get control on the decrypted information. I hope you enjoyed learning with PentesterLab.

35
crypto/hash-length-extension-attack.md
View file

@ -1,35 +0,0 @@
# Hash Length Extension Attack
## Summary of the attack
Imagine a server which is **signing** some **data** by **appending** a **secret** to some known clear text data and then hashing that data. If you know:
* **The length of the secret** \(this can be also bruteforced from a given length range\)
* **The clear text data**
* **The algorithm \(and it's vulnerable to this attack\)**
* **The padding is known**
* Usually a default one is used, so if the other 3 requirements are met, this also is
* The padding vary depending on the length of the secret+data, that's why the length of the secret is needed
Then, it's possible for an **attacker** to **append** **data** and **generate** a valid **signature** for the **previos data + appended data**.
### How?
Basically the vulnerable algorithms generate the hashes by firstly **hashing a block of data**, and then, **from** the **previously** created **hash** \(state\), they **add the next block of data** and **hash it**.
Then, imagine that the secret is "secret" and the data is "data", the MD5 of "secretdata" is 6036708eba0d11f6ef52ad44e8b74d5b.
If an attacker wants to append the string "append" he can:
* Generate a MD5 of 64 "A"s
* Change the state of the previously initialized hash to 6036708eba0d11f6ef52ad44e8b74d5b
* Append the string "append"
* Finish the hash and the resulting hash will be a **valid one for "secret" + "data" + "padding" + "append"**
### **Tool**
{% embed url="https://github.com/iagox86/hash\_extender" %}
## References
You can find this attack good explained in [https://blog.skullsecurity.org/2012/everything-you-need-to-know-about-hash-length-extension-attacks](https://blog.skullsecurity.org/2012/everything-you-need-to-know-about-hash-length-extension-attacks)

125
crypto/padding-oracle-priv.md
View file

@ -1,125 +0,0 @@
---
description: 'https://pentesterlab.com/'
---
# Padding Oracle
**Post from** [**https://pentesterlab.com/**](https://pentesterlab.com/)\*\*\*\*
## Cipher Block Chaining
CBC is an encryption mode in which the message is split into blocks of X bytes length and each block is XORed with the previous encrypted block. The result is then encrypted.
The following schema \(source: [Wikipedia](http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation)\) explains this method:
![CBC encryption](https://assets.pentesterlab.com/padding_oracle/CBC_encryption.png)
During the decryption, the reverse operation is used. The encrypted data is split in block of X bytes. Then the block is decrypted and XORed with the previous encrypted block to get the cleartext. The following schema \(source: [Wikipedia](http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation)\) highlights this behavior:
![CBC decryption](https://assets.pentesterlab.com/padding_oracle/CBC_decryption.png)
Since the first block does not have a previous block, an initialization vector \(IV\) is used.
## Padding
As we saw, the encryption is done by blocks of fixed size. To ensure that the cleartext exactly fit in one or multiple blocks, padding is often used. Padding can be done in multiple ways. A common way is to use PKCS7. With PKCS7, the padding will be composed of the same number: the number of bytes missing. For example, if the cleartext is missing 2 bytes, the padding will be `\x02\x02`.
Let's look at more examples with a 2 blocks:
| Block \#0 | Block \#1 | | | | | | | | | | | | | | |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| byte \#0 | byte \#1 | byte \#2 | byte \#3 | byte \#4 | byte \#5 | byte \#6 | byte \#7 | byte \#0 | byte \#1 | byte \#2 | byte \#3 | byte \#4 | byte \#5 | byte \#6 | byte \#7 |
| 'S' | 'U' | 'P' | 'E' | 'R' | 'S' | 'E' | 'C' | 'R' | 'E' | 'T' | '1' | '2' | '3' | **0x02** | **0x02** |
| 'S' | 'U' | 'P' | 'E' | 'R' | 'S' | 'E' | 'C' | 'R' | 'E' | 'T' | '1' | '2' | **0x03** | **0x03** | **0x03** |
| 'S' | 'U' | 'P' | 'E' | 'R' | 'S' | 'E' | 'C' | 'R' | 'E' | 'T' | **0x05** | **0x05** | **0x05** | **0x05** | **0x05** |
| 'S' | 'U' | 'P' | 'E' | 'R' | 'S' | 'E' | 'C' | **0x08** | **0x08** | **0x08** | **0x08** | **0x08** | **0x08** | **0x08** | **0x08** |
## Padding Oracle
When an application decrypts encrypted data, it will first decrypt the data; then it will remove the padding. During the cleanup of the padding, **if** an **invalid** **padding** triggers a detectable **behaviour**, you have a **padding oracle vulnerability**. The detectable behaviour can be an **error**, a **lack** of **results**, or a **slower response**.
If you detect this behaviour, you can **decrypt the encrypted data** and even **encrypt any cleartext**.
### How to exploit
You could use [https://github.com/AonCyberLabs/PadBuster](https://github.com/AonCyberLabs/PadBuster) to exploit this kind of vulnerability or just do
```text
sudo apt-get install padbuster
```
In order to test if the cookie of a site is vulnerable you could try:
```bash
perl ./padBuster.pl http://10.10.181.45/index.php "Nl0OpaQYeGPMJeWSih2iiQ==" 8 -encoding 0 -cookies "auth=Nl0OpaQYeGPMJeWSih2iiQ=="
```
**Encoding 0** means that **base64** is used \(but others are available, check the help menu\).
You could also **abuse** this **vulnerability** to **encrypt new data**. For example, imagine that the content of the cookie is "_user=MyUsername_", then you may change it to "_**user=administrator**_" and escalate privileges inside the application. You could also do it using `paduster`specifying the **-plaintext** parameter:
```bash
perl ./padBuster.pl http://10.10.181.45/index.php "Nl0OpaQYeGPMJeWSih2iiQ==" 8 -encoding 0 -cookies "auth=Nl0OpaQYeGPMJeWSih2iiQ==" -plaintext "user=administrator"
```
If the site is vulnerable `padbuster`will automatically try to find when the padding error occurs, but you can also indicating the error message it using the **-error** parameter.
```bash
perl ./padBuster.pl http://10.10.181.45/index.php "Nl0OpaQYeGPMJeWSih2iiQ==" 8 -encoding 0 -cookies "hcon=Nl0OpaQYeGPMJeWSih2iiQ==" -error "Invalid padding"
```
### The theory
In **summary**, you can start decrypting the encrypted data by **guessing** the correct **values** that can be used to **create** all the **different paddings**. Then, the padding oracle attack will start **decrypting** bytes **from** the **end** to the start by **guessing** which will be the correct **value** that **creates a padding of 1, 2, 3, etc**.
If we zoom in, we can see that the cleartext byte `C15` is just a XOR between the encrypted byte `E7` from the previous block, and byte `I15` which came out of the block decryption step:
![CBC zoom in](https://assets.pentesterlab.com/padding_oracle/zoomin.png)
This is also valid for all other bytes:
* `C14 = I14 ^ E6`
* `C13 = I13 ^ E5`
* `C12 = I12 ^ E4`
* ...
Now if we modify `E7` and keep changing its value, we will keep getting an invalid padding. Since we need `C15` to be `\x01`. However, there is one value of `E7` that will give us a valid padding. Let's call it `E'7`. With `E'7`, we get a valid padding. And since we know we get a valid padding we know that `C'15` \(as in `C15` for `E'7`\) is `\x01`.
`\x01 = I15 ^ E'7`
The gives us:
`I15 = \x01 ^ E'7`
So we are able to compute `I15`.
Since we know `I15`, we can now compute `C15`
`C15 = E7 ^ I15 = E7 ^ \x01 ^ E'7`
Now that we have `C15`, we can move to brute-forcing `C14`. First we need to compute another `E7` \(let's call it `E''7`\) that gives us `C15 = \x02`. We need to do that since we want the padding to be `\x02\x02` now. It's really simple to compute using the property above and by replacing the value of `C15` we want \(`\x02`\) and `I15` we now know:
`E''7 = \x02 ^ I15`
After brute force `E6`, to find the value that gives us a valid padding `E''6`, we can re-use the formula:
`C14 = I14 ^ E6`
to get
`I14 = \x02 ^ E''6`
Once we get `I14`, we can compute `C14`:
`C14 = E6 ^ I14 = E6 ^ \x02 ^ E''6`
Using this method, we can keep going until we get all the ciphertext decrypted.
### Detection of the vulnerability
To get started, you can register an account and log in with this account \(to make things easier, you get automatically logged in when you register\).
If you create an account and log in two times with this account, you can see that the cookie sent by the application didn't change.If you log in many times and always get the same cookie, there is probably something wrong in the application. The cookie sent back should be unique each time you log in. If the cookie is always the same, it will probably always be valid and there won't be anyway to invalidate it.
Now, if you try to modify the cookie, you can see that you get an error from the application.

14
crypto/rc4-encrypt-and-decrypt.md
View file

@ -1,14 +0,0 @@
# RC4 - Encrypt&Decrypt
If you can somehow encrypt a plaintext using a RC4**,** you can decrypt any content encrypted by that RC4\(using the same password\) just using the encryption function.
If you can encrypt a known plaintext you can also extract the password. More references can be found in the HTB Kryptos machine:
{% embed url="https://0xrick.github.io/hack-the-box/kryptos/" %}
{% embed url="https://0xrick.github.io/hack-the-box/kryptos/" %}
\*\*\*\*