Black Hat Rust Applied offensive security with the Rust programming language (Sylvain Kerkour) (z-library.sk, 1lib.sk, z-lib.sk)

📄 File Format: PDF

💾 File Size: 3.9 MB

📖 Read Online ⬇️ Download

Registered users can read the full content for free

Register as a Gaohf Library member to read the complete e-book online for free and enjoy a better reading experience.

📄 Page 1

Black Hat Rust Applied offensive security with the Rust programming language Sylvain Kerkour

📄 Page 2

Black Hat Rust Applied offensive security with the Rust programming language Sylvain Kerkour v2022.56

📄 Page 3

Contents Copyright 7 Your early access bonuses 8 Contact 9 Preface 10 1 Introduction 13 1.1 Types of attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.2 Phases of an attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.3 Profiles of attackers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.4 Attribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.5 The Rust programming language . . . . . . . . . . . . . . . . . . . . . 19 1.6 History of Rust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.7 Rust is awesome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.8 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 1.9 Our first Rust program: A SHA-1 hash cracker . . . . . . . . . . . . . 25 1.10 Mental models for approaching Rust . . . . . . . . . . . . . . . . . . . 31 1.11 A few things I’ve learned along the way . . . . . . . . . . . . . . . . . . 33 1.12 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 2 Multi-threaded attack surface discovery 42 2.1 Passive reconnaissance . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.2 Active reconnaissance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.3 Assets discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.4 Our first scanner in Rust . . . . . . . . . . . . . . . . . . . . . . . . . . 45 2.5 Error handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 2.6 Enumerating subdomains . . . . . . . . . . . . . . . . . . . . . . . . . 46 2.7 Scanning ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 2.8 Multithreading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 2.9 Fearless concurrency in Rust . . . . . . . . . . . . . . . . . . . . . . . . 49 2.10 The three causes of data races . . . . . . . . . . . . . . . . . . . . . . . 52 2.11 The three rules of ownership . . . . . . . . . . . . . . . . . . . . . . . . 52 2.12 The two rules of references . . . . . . . . . . . . . . . . . . . . . . . . . 52 2.13 Other concurrency problems . . . . . . . . . . . . . . . . . . . . . . . . 53 2.14 Adding multithreading to our scanner . . . . . . . . . . . . . . . . . . . 53 1

📄 Page 4

2.15 Alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 2.16 Going further . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 2.17 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 3 Going full speed with async 58 3.1 Why . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.2 Cooperative vs Preemptive scheduling . . . . . . . . . . . . . . . . . . 59 3.3 Future . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 3.4 Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 3.5 What is a runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 3.6 Introducing tokio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 3.7 Avoid blocking the event loops . . . . . . . . . . . . . . . . . . . . . . . 64 3.8 Sharing data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 3.9 Combinators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 3.10 Porting our scanner to async . . . . . . . . . . . . . . . . . . . . . . . . 82 3.11 How to defend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 3.12 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 4 Adding modules with trait objects 88 4.1 Generics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 4.2 Traits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 4.3 Traits objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 4.4 Command line argument parsing . . . . . . . . . . . . . . . . . . . . . 100 4.5 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 4.6 Adding modules to our scanner . . . . . . . . . . . . . . . . . . . . . . 102 4.7 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 4.8 Other scanners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 4.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 5 Crawling the web for OSINT 114 5.1 OSINT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 5.2 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 5.3 Search engines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 5.4 IoT & network Search engines . . . . . . . . . . . . . . . . . . . . . . . 117 5.5 Social media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 5.6 Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 5.7 Videos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 5.8 Government records . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 5.9 Crawling the web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 5.10 Why Rust for crawling . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 5.11 Associated types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 5.12 Atomic types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 5.13 Barrier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 5.14 Implementing a crawler in Rust . . . . . . . . . . . . . . . . . . . . . . 124 5.15 The spider trait . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 5.16 Implementing the crawler . . . . . . . . . . . . . . . . . . . . . . . . . 125 5.17 Crawling a simple HTML website . . . . . . . . . . . . . . . . . . . . . 129 2

📄 Page 5

5.18 Crawling a JSON API . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 5.19 Crawling a JavaScript web application . . . . . . . . . . . . . . . . . . 133 5.20 How to defend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 5.21 Going further . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 5.22 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 6 Finding vulnerabilities 139 6.1 What is a vulnerability . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 6.2 Weakness vs Vulnerability (CWE vs CVE) . . . . . . . . . . . . . . . . 139 6.3 Vulnerability vs Exploit . . . . . . . . . . . . . . . . . . . . . . . . . . 140 6.4 0 Day vs CVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 6.5 Web vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 6.6 Injections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 6.7 HTML injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 6.8 SQL injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 6.9 XSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 6.10 Server Side Request Forgery (SSRF) . . . . . . . . . . . . . . . . . . . 147 6.11 Cross-Site Request Forgery (CSRF) . . . . . . . . . . . . . . . . . . . . 149 6.12 Open redirect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 6.13 (Sub)Domain takeover . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 6.14 Arbitrary file read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 6.15 Denial of Service (DoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 6.16 Arbitrary file write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 6.17 Memory vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 6.18 Buffer overflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 6.19 Use after free . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 6.20 Double free . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 6.21 Other vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 6.22 Remote Code Execution (RCE) . . . . . . . . . . . . . . . . . . . . . . 160 6.23 Integer overflow (and underflow) . . . . . . . . . . . . . . . . . . . . . . 161 6.24 Logic error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 6.25 Race condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 6.26 Additional resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 6.27 Bug hunting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 6.28 The tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 6.29 Automated audits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 6.30 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 7 Exploit development 173 7.1 Where to find exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 7.2 Creating a crate that is both a library and a binary . . . . . . . . . . . 174 7.3 libc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 7.4 Building an exploitation toolkit . . . . . . . . . . . . . . . . . . . . . . 176 7.5 CVE-2019-11229 && CVE-2019-89242 . . . . . . . . . . . . . . . . . . 176 7.6 CVE-2021-3156 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 7.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 3

📄 Page 6

8 Writing shellcodes in Rust 182 8.1 What is a shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 8.2 Sections of an executable . . . . . . . . . . . . . . . . . . . . . . . . . . 183 8.3 Rust compilation process . . . . . . . . . . . . . . . . . . . . . . . . . . 184 8.4 no_std . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 8.5 Using assembly from Rust . . . . . . . . . . . . . . . . . . . . . . . . . 186 8.6 The never type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 8.7 Executing shellcodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 8.8 Our linker script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 8.9 Hello world shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 8.10 An actual shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 8.11 Reverse TCP shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 8.12 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 9 Phishing with WebAssembly 204 9.1 Social engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 9.2 Nontechnical hacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 9.3 Phishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 9.4 Watering holes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210 9.5 Telephone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 9.6 WebAssembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 9.7 Sending emails in Rust . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 9.8 Implementing a phishing page in Rust . . . . . . . . . . . . . . . . . . 218 9.9 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 9.10 Cargo Workspaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 9.11 Deserialization in Rust . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 9.12 A client application with WebAssembly . . . . . . . . . . . . . . . . . . 220 9.13 Evil twin attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 9.14 How to defend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 9.15 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 10 A modern RAT 235 10.1 Architecture of a RAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 10.2 C&C channels & methods . . . . . . . . . . . . . . . . . . . . . . . . . 237 10.3 Existing RAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 10.4 Why Rust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 10.5 Designing the server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 10.6 Designing the agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 10.7 Docker for offensive security . . . . . . . . . . . . . . . . . . . . . . . . 252 10.8 Let’s code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 10.9 Optimizing Rust’s binary size . . . . . . . . . . . . . . . . . . . . . . . 273 10.10Dockerizing the server . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 10.11Some limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 10.12Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 11 Securing communications with end-to-end encryption 276 11.1 The C.I.A triad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276 4

📄 Page 7

11.2 Threat modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 11.3 Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 11.4 Hash functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 11.5 Message Authentication Codes . . . . . . . . . . . . . . . . . . . . . . . 279 11.6 Key derivation functions . . . . . . . . . . . . . . . . . . . . . . . . . . 281 11.7 Block ciphers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281 11.8 Authenticated encryption (AEAD) . . . . . . . . . . . . . . . . . . . . 282 11.9 Asymmetric encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 11.10Diffie–Hellman key exchange . . . . . . . . . . . . . . . . . . . . . . . . 285 11.11Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 11.12End-to-end encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 11.13Who uses cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . 295 11.14Common problems and pitfalls with cryptography . . . . . . . . . . . . 296 11.15A little bit of TOFU? . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 11.16The Rust cryptography ecosystem . . . . . . . . . . . . . . . . . . . . . 297 11.17Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 11.18Our threat model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299 11.19Designing our protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 300 11.20Implementing end-to-end encryption in Rust . . . . . . . . . . . . . . . 304 11.21Some limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314 11.22To learn more . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 11.23Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 12 Going multi-platforms 317 12.1 Why multi-platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 12.2 Cross-platform Rust . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 12.3 Supported platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 12.4 Cross-compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 12.5 cross . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 12.6 Custom Dockerfiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 12.7 Cross-compiling to aarch64 (arm64) . . . . . . . . . . . . . . . . . . . . 323 12.8 More Rust binary optimization tips . . . . . . . . . . . . . . . . . . . . 324 12.9 Packers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 12.10Persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 12.11Single instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330 12.12Going further . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 12.13Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 13 Turning our RAT into a worm to increase reach 332 13.1 What is a worm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332 13.2 Spreading techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 13.3 Cross-platform worm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335 13.4 Spreading through SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 336 13.5 Vendoring dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . 337 13.6 Implementing a cross-platform worm in Rust . . . . . . . . . . . . . . . 338 13.7 Install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 13.8 Spreading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340 5

📄 Page 8

13.9 More advanced techniques for your RAT . . . . . . . . . . . . . . . . . 344 13.10Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 14 Conclusion 349 14.1 What we didn’t cover . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349 14.2 The future of Rust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 14.3 Leaked repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 14.4 How bad guys get caught . . . . . . . . . . . . . . . . . . . . . . . . . 351 14.5 Your turn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352 14.6 Build your own RAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 14.7 Other interesting blogs . . . . . . . . . . . . . . . . . . . . . . . . . . . 356 14.8 Contact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356 6

📄 Page 9

Copyright Copyright © 2021 Sylvain Kerkour All rights reserved. No portion of this book may be reproduced in any form without permission from the publisher, except as permitted by law. For permissions contact: sylvain@kerkour.com 7

📄 Page 10

Your early access bonuses Dear reader, in order to thank you for buying the Black Hat Rust early access edition and helping to make this book a reality, I prepared you a special bonus: I curated a list of the best detailed analyses of the most advanced malware of the past two decades. You may find inside great inspiration when developing your own offensive tools. You can find the list at this address: https://github.com/black-hat-rust-bonuses/black- hat-rust-bonuses If you notice a mistake (it happens), something that could be improved, or want to share your ideas about offensive security, feel free to join the discussion on Github: https://github.com/skerkour/black-hat-rust 8

📄 Page 11

Contact I regularly publish content that is complementary to this book in my newsletter. Every week I share updates about my projects and everything I learn about how to (ab)use technology for fun & profit: Programming, Hacking & Entrepreneurship. You can subscribe by Email or RSS: https://kerkour.com/follow. You bought the book and are annoyed by something? Please tell me, and I will do my best to improve it! Or, you greatly enjoyed the read and want to say thank you? Feel free to contact me by email: sylvain@kerkour.com or matrix: @sylvain:kerkour.com You can find all the updates in the changelog. 9

📄 Page 12

Preface After high school, my plan for life was to become a private detective, maybe because I read too many Sherlock Holmes books. In France, the easiest way to become one is (was?) to go to law university and then to attend a specialized school. I was not ready. I quickly realized that studying law was not for me: reality is travestied to fit whatever narrative politics or professor wanted us to believe. No deep knowledge is taught here, only numbers, dates, how to look nice and sound smart. It was deeply frustrating for the young man I was, with an insatiable curiosity. I wanted to understand how the world works, not human conventions. For example, how do these machines we call computers that we are frantically typing on all day long work under the hood? So I started by installing Linux (no, I won’t enter the GNU/Linux war) on my Asus EeePC, a small netbook with only 1GB of RAM, because Windows was too slow, and started to learn to develop C++ programs with Qt, thanks to online tutorials. I coded my own text and my own chat systems. But my curiosity was not fulfilled. One day, I inadvertently fell on the book that changed my life: “Hacking: The Art of Exploitation, 2nd Edition”, by Jon Erickson. This book not only made me curious about how to make things, but, more importantly, how to break things. It made me realize that you can’t build reliable things without understanding how to break them, and by extension, where their weaknesses are. While the book remains great to learn low-level programming and how to exploit simple memory safety bugs, today, hacking requires new skills: web exploitation, network and system programming, and, above all, how to code in a modern programming language. Welcome to the fascinating world of Rust and offensive security. While the Rust Book does an excellent job teaching What is Rust, I felt that a book about Why and How to Rust was missing. That means that some concepts will not 10

📄 Page 13

be covered in-depth in this book. Instead, we are going to see how to effectively use them in practice. In this book, we will shake the preconceived ideas (Rust is too complex for the real world, Rust is not productive…) and see how to architect and create real-world Rust projects applied to offensive security. We will see how polyvalent Rust is, which enables its users to replace the plethora of programming languages (Python, Ruby, C, C++…) plaguing the offensive security world with a unique language that offers high-level abstractions, high performance, and low-level control when needed. We will always start with some theory, deep knowledge that pass through ages, tech- nologies and trends. This knowledge is independent of any programming language and will help you to get the right mindset required for offensive security. I designed this book for people who either want to understand how attackers think in order to better defend themselves or for people who want to enter the world of offensive security and eventually make a living off it. The goal of this book is to save you time in your path to action, by distilling knowledge and presenting it in applied code projects. It’s important to understand that Black Hat Rust is not meant to be a big encyclopedia containing all the knowledge of the world. Instead, it was designed as a guide to help you getting started and pave the way to action. Knowledge is often a prerequisite, but it’s action that is shaping the world, and sometimes knowledge is a blocker for action (see analysis paralysis). As we will see, some of the most primitive offensive techniques are still the most effective. Thus some very specific topics, such as how to bypass modern OSes protection mechanisms won’t be covered because there already is extensive literature on these topics, and they have little value in a book about Rust. That being said, I did my best to list the best resources to further your learning journey. It took me approximately 1 year to become efficient in Rust, but it’s only when I started to write (and rewrite) a lot of code that I made real progress. Rust is an extremely vast language, but in reality, you will (and should) use only a subset of its features: you don’t need to learn them all ahead of time. Some, that we will study in this book, are fundamentals. Others are not and may have an adversarial effect on the quality of your code by making it harder to read and maintain. My intention with this book is not only to make you discover the fabulous world of offensive security, to convince you that Rust is the long-awaited one-size-fits-all pro- gramming language meeting all the needs of offensive security, but also to save you 11

📄 Page 14

a lot of time by guiding you to what really matters when learning Rust and offensive security. But remember, knowledge is not enough. Knowledge doesn’t move mountains. Actions do. Thus, the book is only one half of the story. The other half is the accompanying code repository: https://github.com/skerkour/black-hat-rust. It’s impossible to learn without practice, so I invite you to read the code, modify it and make it yours! If at any time you feel lost or don’t understand a chunk of Rust code, don’t hesitate to refer to the Rust Language Cheat Sheet, The Rust Book, and the Rust Language Reference. Also, the book is code-heavy. I recommend reading it with a web browser aside, in order to explore and play with the code on GitHub: https://github.com/skerkour/black-hat- rust/. 12

📄 Page 15

Chapter 1 Introduction “Any sufficiently advanced cyberattack is indistinguishable from magic”, unknown Whether it be in movies or in mainstream media, hackers are often romanticized: they are depicted as black magic wizards, nasty criminals, or, in the worst cases, as thieves with a hood and a crowbar. In reality, the spectrum of the profile of the attackers is extremely large, from the bored teenager exploring the internet to sovereign State’s armies as well as the unhappy former employee. As we will see, cyberattacks are not that hard. Knowledge is simply unevenly distributed and jealously kept secret by the existing actors. The principal ingredients are a good dose of curiosity and the courage to follow your instinct. As digital is taking an always more important place in our lives, the impact and scale of cyberattacks will increase in the same way: we are helplessly witnessing during the current COVID-19 pandemic attacks against our hospitals which have real-life and dramatic consequences. It’s time to fight back and to prepare ourselves for the wars and battles of today (not tomorrow) and to understand that, in order to defend, there is no other way than to put ourselves in the shoes of attackers and think how they think. What are their motivations? How can they break seemingly so easily into any system? What do they do to their victims? From theory to practice, we will explore the arcanes of offensive security and build our own offensive tools with the Rust programming language. Why Rust? The world of security (and, more generally, software) is plagued by too many program- ming languages with too many footguns. You have to choose between fast and unsafe (C, C++…) or slow but mostly safe (Python, Java…). 13

📄 Page 16

Can someone be an expert in all these languages? I don’t think so. And the countless bugs and vulnerabilities in offensive tools prove I’m right. What if, instead, we could have a unique language. A language that, once mastered, would fill all the needs of the field: • Shellcodes • Cross-platform Remote Access Tools (RATs) • Reusable and embeddable exploits • Scanners • Phishing toolkits • Embedded programming • Web servers • … What if we had a single language that is low-level enough while providing high-level abstractions, is exceptionally fast, and easy to cross-compile. All of that while being memory safe, highly reusable, and extremely reliable. No more weird toolchains, strange binary packagers, vulnerable network code, injectable phishing forms… You got it, Rust is the language to rule them all. Due to momentum, Rust isn’t widely adopted by the security industry yet, but once the tech leads and independent hackers understand this reality, I believe that the change will happen really fast. Of course, there are some pitfalls and a few things to know, but everything is covered in the following chapters. 1.1 Types of attacks All attacks are not necessarily illegal or unsolicited. Let’s start with a quick summary of the most common kinds of attacks found in the wild. 1.1.1 Attacks without a clear goal Teenagers have an obscene amount of free time. Thus, some of them may start learning computer security after school and hack random targets on the internet. Even if they may not have clear goals in mind other than inflating their ego and appeasing their curiosity, these kinds of attacks can still have substantial monetary costs for the victims. 14

📄 Page 17

1.1.2 Political attacks Sometimes, attacks have the only goal of spreading a political message. Most of the time, they materialize as website defacements where websites’ content is replaced with the political message, or denial-of-service attacks where a piece of infrastructure or a service is made unavailable. 1.1.3 Pentest Pentest, which stands for Penetration Testing, may be the most common term used to designate security audits. One downside of pentests is that sometimes they are just a means to check boxes for compliance purposes, are performed using simple automated scanners, and may leave big holes open. 1.1.4 Red team Red teaming is seen as an evolution of traditional pentests: attackers are given more permissions and a broader scope like phishing employees, using implants or even physical penetration. The idea is: in order to protect against attacks, auditors have to think and operate like real attackers. 1.1.5 Bug bounty Bug bounty programs are the uberization of security audits. Basically, companies say: “Try to hack me. If you find something and report it to me, I will pay you”. As we will see in the last chapter, bug bounty programs have their limits and are sometimes used by companies as virtue signaling instead of real security measures. 1.1.6 Cybercrime Cybercrime is definitely the most growing type of attack since the 2010s. From selling personal data on underground forums to botnets and ransomwares or credit card hack- ing, criminal networks have found many creative ways of acting. An important peak occurred in 2017, when the NSA tools and exploits were leaked by the mysterious group “Shadow Brokers”, which were then used in other malware such as WanaCry and Petya. Despite the strengthening of online services to reduce the impact of data-stealing (today, it is far more difficult to take advantage of a stolen card number compared to a few years ago), criminals always find new creative ways to monetize their wrongdoings, especially with cryptocurrencies. 15

📄 Page 18

1.1.7 Industrial spying Industrial espionage has always been a tempting means for companies to break down competitors’ secrets and achieve competitive advantage. As our economy is more and more dematerialized (digitalized), this kind of attack will only increase in terms of frequency. 1.1.8 Cyberwar This last kind of attack is certainly the less mediatized but without doubt the most spectacular. To learn more about this exciting topic, I can’t recommend enough the excellent book “Countdown to Zero Day: Stuxnet and the Launch of the World’s First Digital Weapon” by Kim Zetter which tells the story of, to my knowledge, the first act of advanced cyberwar: the Stuxnet worm. 1.2 Phases of an attack Figure 1.1: Phases of an attack 1.2.1 Reconnaissance The first phase consists of gathering as much information as possible about the target. Whether it be the names of the employees, the numbers of internet-facing machines and the services running on them, the list of the public Git repositories… Reconnaissance is either passive (using publicly available data sources, such as social networks or search engines), or active (scanning the target’s networks directly, for ex- ample). 1.2.2 Exploitation Exploitation is the initial breach. It can be performed by using exploits (zero-day or not), abusing humans (social engineering) or both (sending office documents with malware inside). 16

📄 Page 19

1.2.3 Lateral Movements Also known as pivoting, lateral movement designates the process of maintaining access and gaining access to more resources and systems. Implants, Remote Access Tools (RATs), and various other tools are used during this phase. The biggest challenge is to stay hidden as long as possible. 1.2.4 Data exfiltration Data exfiltration is not present in every cyberattack, but in most which are not carried out by criminals: industrial spying, banking trojans, State spying… It should be made with care as large chunks of data passing through the network may not go unnoticed. 1.2.5 Clean up Once the attack is successfully completed, advised attackers need to cover their tracks in order to reduce the risk of being identified: logs, temporary files, infrastructure, phishing websites… 1.3 Profiles of attackers The profile of attackers is also extremely varied. From lone wolves to teams of hackers, developers and analysts, there is definitely not a common profile that fits them all. However, in this section, I will try to portray which profiles should be part of a team conducting offensive operations. 1.3.1 The hacker The term hacker is controversial: mainstream media use it to describe criminals while tech people use it to describe passionate or hobbyists tinkering with tech. In our context, we will use it to describe the person with advanced offensive skills and whose role is to perform reconnaissance and exploitation of the targets. 1.3.2 The exploit writer The exploit writers are often developers with a deep understanding of security. Their role is to craft the weapons used by their teams to break into their targets’ networks and machines. 17

📄 Page 20

Exploit development is also known as “weaponization”. Entire companies are operating in the grey waters of exploits trading, such as Vupen or Zerodium. They often don’t find the exploits themselves but buy them from third-party hackers and find buyers (such as government agencies or malware developers). 1.3.3 The developer The role of the developer is to build custom tools (credential dumpers, proxies…) and implants used during the attack. Indeed, using publicly available, pre-made tools vastly increase the risk of being detected. These are the skills we will learn and practice in the next chapters. 1.3.4 The system administrator Once the initial compromise is performed, the role of the system administrator is to operate and secure the infrastructure used by attackers. Their knowledge can also be used during the exploitation and lateral movements phases. 1.3.5 The analyst In all kinds of attacks, domain knowledge is required to interpret the findings and prioritize targets. This is the role of the analyst, either to provide deep knowledge about what specifically to target or to make sense of the exfiltrated data. 1.4 Attribution Attribution is the process of identifying and laying blame on the operators behind a cyber attack. As we will see, it’s an extremely complex topic: sophisticated attackers go through multiple networks and countries before hitting their target. Attacks attribution is usually based on the following technical and operational elements: Dates and time of the attackers’ activities, which may reveal their time zone - even though it can easily be manipulated by moving the team to another country. Artifacts present in the employed malware, like a string of characters in a specific alphabet or language - although, one can insert another language in order to blame someone else. 18