Black Hat Rust (Sylvain Kerkour) (Z-Library)

📄 File Format: PDF

💾 File Size: 3.6 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 Deep dive into offensive security with the Rust programming language Sylvain Kerkour v2021.23

📄 Page 3

Contents 1 Copyright 8 2 Your early access bonuses 9 3 Beta & Contact 10 4 Preface 11 5 Introduction 14 5.1 Types of attacks . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2 Phases of an attack . . . . . . . . . . . . . . . . . . . . . . . . 17 5.3 Profiles of attackers . . . . . . . . . . . . . . . . . . . . . . . . 18 5.4 Attribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.5 The Rust programming language . . . . . . . . . . . . . . . . 20 5.6 History of Rust . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.7 Rust is awesome . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.8 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.9 Our first Rust program: A SHA-1 hash cracker . . . . . . . . 26 5.10 Mental models to approach Rust . . . . . . . . . . . . . . . . 33 5.11 A few things I’ve learned along the way . . . . . . . . . . . . . 35 5.12 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 6 Multi-threaded attack surface discovery 45 6.1 Passive reconnaissance . . . . . . . . . . . . . . . . . . . . . . 46 6.2 Active reconnaissance . . . . . . . . . . . . . . . . . . . . . . . 46 6.3 Assets discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 47 6.4 Our first scanner in Rust . . . . . . . . . . . . . . . . . . . . . 48 6.5 Error handling . . . . . . . . . . . . . . . . . . . . . . . . . . 49 1

📄 Page 4

6.6 Enumerating subdomains . . . . . . . . . . . . . . . . . . . . 49 6.7 Scanning ports . . . . . . . . . . . . . . . . . . . . . . . . . . 50 6.8 Multithreading . . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.9 Fearless concurrency in Rust . . . . . . . . . . . . . . . . . . . 53 6.10 The three causes of data races . . . . . . . . . . . . . . . . . . 56 6.11 The three rules of ownership . . . . . . . . . . . . . . . . . . . 56 6.12 The two rules of references . . . . . . . . . . . . . . . . . . . . 56 6.13 Adding multithreading to our scanner . . . . . . . . . . . . . . 56 6.14 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 7 Going full speed with async 61 7.1 Why . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 7.2 Cooperative vs Preemptive scheduling . . . . . . . . . . . . . 62 7.3 Future . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 7.4 Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 7.5 What is a runtime . . . . . . . . . . . . . . . . . . . . . . . . 63 7.6 Introducing tokio . . . . . . . . . . . . . . . . . . . . . . . . . 64 7.7 Sharing data . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 7.8 Avoid blocking . . . . . . . . . . . . . . . . . . . . . . . . . . 67 7.9 Combinators . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 7.10 Porting our scanner to async . . . . . . . . . . . . . . . . . . . 80 7.11 How to defend . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 7.12 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 8 Adding modules with trait objects 82 8.1 Generics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 8.2 Traits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 8.3 Traits objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 8.4 Command line argument parsing . . . . . . . . . . . . . . . . 93 8.5 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 8.6 Adding modules to our scanner . . . . . . . . . . . . . . . . . 95 8.7 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 8.8 Other scanners . . . . . . . . . . . . . . . . . . . . . . . . . . 107 8.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 9 Crawling the web for OSINT 108 9.1 OSINT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 9.2 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 2

📄 Page 5

9.3 Search engines . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 9.4 IoT & network Search engines . . . . . . . . . . . . . . . . . . 111 9.5 Social media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 9.6 Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 9.7 Videos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 9.8 Government records . . . . . . . . . . . . . . . . . . . . . . . 112 9.9 Crawling the web . . . . . . . . . . . . . . . . . . . . . . . . . 113 9.10 Why Rust for crawling . . . . . . . . . . . . . . . . . . . . . . 115 9.11 Associated types . . . . . . . . . . . . . . . . . . . . . . . . . 115 9.12 Atomic types . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 9.13 Barrier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 9.14 Implementing a crawler in Rust . . . . . . . . . . . . . . . . . 118 9.15 The spider trait . . . . . . . . . . . . . . . . . . . . . . . . . . 118 9.16 Implementing the crawler . . . . . . . . . . . . . . . . . . . . 118 9.17 Crawling a simple HTML website . . . . . . . . . . . . . . . . 122 9.18 Crawling a JSON API . . . . . . . . . . . . . . . . . . . . . . 124 9.19 Crawling a JavaScript web application . . . . . . . . . . . . . 127 9.20 How to defend . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 9.21 Going further . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 9.22 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 10 Finding vulnerabilities 133 10.1 What is a vulnerability . . . . . . . . . . . . . . . . . . . . . . 133 10.2 CWE vs CVE . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 10.3 Vulnerability vs Exploit . . . . . . . . . . . . . . . . . . . . . 134 10.4 0 Day vs CVE . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 10.5 Web vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . 135 10.6 Injections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 10.7 HTML injection . . . . . . . . . . . . . . . . . . . . . . . . . . 135 10.8 SQL injection . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 10.9 XSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 10.10Server Side Request Forgery (SSRF) . . . . . . . . . . . . . . 142 10.11Cross-Site Request Forgery (CSRF) . . . . . . . . . . . . . . . 144 10.12Open redirect . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 10.13(Sub)Domain takeover . . . . . . . . . . . . . . . . . . . . . . 147 10.14Arbitrary file read . . . . . . . . . . . . . . . . . . . . . . . . 148 10.15Denial of Service (DoS) . . . . . . . . . . . . . . . . . . . . . . 150 10.16Arbitrary file write . . . . . . . . . . . . . . . . . . . . . . . . 152 3

📄 Page 6

10.17Memory vulnerabilities . . . . . . . . . . . . . . . . . . . . . . 153 10.18Buffer overflow . . . . . . . . . . . . . . . . . . . . . . . . . . 154 10.19Use after free . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 10.20Double free . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 10.21Format string problems . . . . . . . . . . . . . . . . . . . . . . 157 10.22Other vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . 157 10.23Remote Code Execution (RCE) . . . . . . . . . . . . . . . . . 157 10.24Integer overflow (and underflow) . . . . . . . . . . . . . . . . . 159 10.25Logic error . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 10.26Race condition . . . . . . . . . . . . . . . . . . . . . . . . . . 161 10.27Additional resources . . . . . . . . . . . . . . . . . . . . . . . 161 10.28Bug hunting . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 10.29The tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 10.30Automated audits . . . . . . . . . . . . . . . . . . . . . . . . . 166 10.31Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 11 Exploit development 172 11.1 Creating a crate that is both a library and a binary . . . . . . 172 11.2 Building our pwntoolkit . . . . . . . . . . . . . . . . . . . . . 172 11.3 CVE-2017-9506 . . . . . . . . . . . . . . . . . . . . . . . . . . 173 11.4 CVE-2018-7600 . . . . . . . . . . . . . . . . . . . . . . . . . . 173 11.5 CVE-2019-11229 . . . . . . . . . . . . . . . . . . . . . . . . . 175 11.6 CVE-2019-89242 . . . . . . . . . . . . . . . . . . . . . . . . . 180 11.7 CVE-2021-3156 . . . . . . . . . . . . . . . . . . . . . . . . . . 186 11.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 12 Writing shellcodes in Rust 191 12.1 What is a shellcode . . . . . . . . . . . . . . . . . . . . . . . . 191 12.2 Sections of an executable . . . . . . . . . . . . . . . . . . . . . 193 12.3 Rust compilation process . . . . . . . . . . . . . . . . . . . . . 193 12.4 no_std . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 12.5 Using assembly from Rust . . . . . . . . . . . . . . . . . . . . 196 12.6 The never type . . . . . . . . . . . . . . . . . . . . . . . . . . 197 12.7 Executing shellcodes . . . . . . . . . . . . . . . . . . . . . . . 198 12.8 Our linker script . . . . . . . . . . . . . . . . . . . . . . . . . 199 12.9 Hello world shellcode . . . . . . . . . . . . . . . . . . . . . . . 200 12.10An actual shellcode . . . . . . . . . . . . . . . . . . . . . . . . 203 4

📄 Page 7

12.11Reverse TCP shellcode . . . . . . . . . . . . . . . . . . . . . . 210 12.12Going further . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 12.13Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 13 Phishing with WebAssembly 215 13.1 Social engineering . . . . . . . . . . . . . . . . . . . . . . . . . 215 13.2 Nontechnical hacks . . . . . . . . . . . . . . . . . . . . . . . . 220 13.3 Phishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221 13.4 Watering holes . . . . . . . . . . . . . . . . . . . . . . . . . . 222 13.5 Evil twin attack . . . . . . . . . . . . . . . . . . . . . . . . . . 225 13.6 Telephone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 13.7 WebAssembly . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 13.8 Sending emails in Rust . . . . . . . . . . . . . . . . . . . . . . 227 13.9 Implementing a phishing page in Rust . . . . . . . . . . . . . 233 13.10Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 13.11Cargo Workspaces . . . . . . . . . . . . . . . . . . . . . . . . 234 13.12Deserialization in Rust . . . . . . . . . . . . . . . . . . . . . . 234 13.13A client application with WebAssembly . . . . . . . . . . . . . 235 13.14How to defend . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 13.15Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 14 A modern RAT 247 14.1 Architecture of a RAT . . . . . . . . . . . . . . . . . . . . . . 248 14.2 Existing RAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 14.3 Why Rust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 14.4 Designing the server . . . . . . . . . . . . . . . . . . . . . . . 254 14.5 Designing the agent . . . . . . . . . . . . . . . . . . . . . . . . 264 14.6 Docker for offensive security . . . . . . . . . . . . . . . . . . . 265 14.7 Let’s code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 14.8 Optimizing Rust’s binary size . . . . . . . . . . . . . . . . . . 284 14.9 Some limitations . . . . . . . . . . . . . . . . . . . . . . . . . 285 14.10Distributing you RAT . . . . . . . . . . . . . . . . . . . . . . 286 14.11Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 15 Securing communications with end-to-end encryption 287 15.1 The C.I.A triad . . . . . . . . . . . . . . . . . . . . . . . . . . 288 15.2 Threat modeling . . . . . . . . . . . . . . . . . . . . . . . . . 289 15.3 Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . 289 5

📄 Page 8

15.4 Hash functions . . . . . . . . . . . . . . . . . . . . . . . . . . 290 15.5 Message Authentication Codes . . . . . . . . . . . . . . . . . . 291 15.6 Key derivation functions . . . . . . . . . . . . . . . . . . . . . 292 15.7 Block ciphers . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 15.8 Authenticated encryption . . . . . . . . . . . . . . . . . . . . 293 15.9 Asymmetric encryption . . . . . . . . . . . . . . . . . . . . . . 296 15.10Key exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . 296 15.11Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297 15.12End-to-end encryption . . . . . . . . . . . . . . . . . . . . . . 298 15.13Who use cryptography . . . . . . . . . . . . . . . . . . . . . . 299 15.14Common problems and pitfalls with cryptography . . . . . . . 301 15.15A little bit of TOFU? . . . . . . . . . . . . . . . . . . . . . . 302 15.16The Rust cryptography ecosystem . . . . . . . . . . . . . . . . 303 15.17ring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 15.18Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 15.19Our threat model . . . . . . . . . . . . . . . . . . . . . . . . . 305 15.20Designing our protocol . . . . . . . . . . . . . . . . . . . . . . 306 15.21Implementing end-to-end encryption in Rust . . . . . . . . . . 310 15.22Some limitations . . . . . . . . . . . . . . . . . . . . . . . . . 320 15.23To learn more . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 15.24Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322 16 Going multi-platforms 323 16.1 Why multi-platform . . . . . . . . . . . . . . . . . . . . . . . 323 16.2 Cross-platform Rust . . . . . . . . . . . . . . . . . . . . . . . 324 16.3 Supported platforms . . . . . . . . . . . . . . . . . . . . . . . 325 16.4 Cross-compilation . . . . . . . . . . . . . . . . . . . . . . . . . 326 16.5 cross . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 16.6 Custom Dockerfiles . . . . . . . . . . . . . . . . . . . . . . . . 328 16.7 Cross-compiling to aarch64 (arm64) . . . . . . . . . . . . . . . 329 16.8 More Rust binary optimization tips . . . . . . . . . . . . . . . 330 16.9 Packers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 16.10Persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332 16.11Single instance . . . . . . . . . . . . . . . . . . . . . . . . . . 337 16.12Going further . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 16.13Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 17 Turning our RAT into a worm to increase reach 338 6

📄 Page 9

17.1 What is a worm . . . . . . . . . . . . . . . . . . . . . . . . . . 338 17.2 Spreading techniques . . . . . . . . . . . . . . . . . . . . . . . 338 17.3 Cross-platform worm . . . . . . . . . . . . . . . . . . . . . . . 341 17.4 Vendoring dependencies . . . . . . . . . . . . . . . . . . . . . 342 17.5 Spreading through SSH . . . . . . . . . . . . . . . . . . . . . . 343 17.6 Implementing a cross-platform worm in Rust . . . . . . . . . . 343 17.7 Install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344 17.8 Spreading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 17.9 More advanced techniques for your RAT . . . . . . . . . . . . 349 17.10Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 18 Conclusion 354 18.1 What we didn’t cover . . . . . . . . . . . . . . . . . . . . . . . 354 18.2 The future of Rust . . . . . . . . . . . . . . . . . . . . . . . . 356 18.3 Leaked repositories . . . . . . . . . . . . . . . . . . . . . . . . 357 18.4 How bad guys get caught . . . . . . . . . . . . . . . . . . . . 357 18.5 Your turn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 18.6 Build your own RAT . . . . . . . . . . . . . . . . . . . . . . . 361 18.7 Social media . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362 18.8 Other interesting blogs . . . . . . . . . . . . . . . . . . . . . . 362 18.9 Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362 7

📄 Page 10

Chapter 1 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 8

📄 Page 11

Chapter 2 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 9

📄 Page 12

Chapter 3 Beta & Contact This version of the book is not the final edition: there can be layout issues, most of the illustrations will be refined, some things may be in the wrong order, and content may be added according to the feedback I will receive. All the holes in the text are being filled, day after day :) Also, I fix typos and grammatical errors every 2 weeks, so there can be some mistakes during the interval. The final edition of the book is expected for end of Q3 2021. You can find all the updates in the changelog. You can contact me by email: sylvain@kerkour.com or matrix: @syl- vain:kerkour.com 10

📄 Page 13

Chapter 4 Preface After high school, my plan for life was to become a private detective, maybe because I read too much Sherlock Holmes books. In France, the easiest way to become one, is (was?) to go to law university and then to a specialized school. I was not ready. I quickly realized that studying law was not for me: reality was travestied to fit whatever narrative politics or professor wanted us to believe. No deep knowledge was teached 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 conven- tions. What is really energy? And, how these machine 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, coded my own text, 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 11

📄 Page 14

reliable things without understanding how to break them, and by extension where are their weaknesses. While the book remains great to learn low-level programming and how to ex- ploit memory safety bugs, today, hacking requires new skills: web exploita- tion, 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 be covered in depth but instead we will 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 lan- guages (Python, Ruby, C, C++…) plaguing the offensive security world with an unique language (to rule them all) which 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, technologies and trends. This knowledge is independent of any pro- gramming 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. 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 an big encyclopaedia 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 this is action that is shaping the world, and sometime 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 12

📄 Page 15

protection mechanisms won’t be covered because there already is extensive literature on the matter 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, but 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 programming language meeting all the needs of offensive security, but also to save you a lot of time by guiding you to what really matters when learning Rust and offensive security. But 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 accom- panying 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. 13

📄 Page 16

Chapter 5 Introduction “Any sufficiently advanced cyberattack is indistinguishable from magic”, un- known Whether it be in movies or in mainstream media, hackers are often roman- ticized: they are painted 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 jealously kept secret by the existing actors. The principal ingredients being 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 as we are helplessly witnessing during the current 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, 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 the motivations of the attackers? 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 14

📄 Page 17

tools with the Rust programming language. 5.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. 5.1.1 Attacks without clear goal Teenagers have an obscene amount of free time so it may happen that some of them 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, this kind of attack can still have monetary costs for the victims. 5.1.2 Political attacks Sometimes, attacks have the only goal of spreading a political message. Most often they materialize as website defacements where websites’ content is re- placed with the political message, or denial-of-service attacks where an in- frastructure is made unavailable. 5.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 some boxes for compliance purposes, are performed using simple automated scanners and may leave big holes open. 5.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. 15

📄 Page 18

5.1.5 Bug bounty Bug bounty programs are the uberization of security audits. Basically, com- panies say “Try to hack me, and if you find something and report it to me, I will pay you”. 5.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 ran- somwares, or to credit card hacking, 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 like 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 few years ago), criminals always find new creative ways to monetize their wrongdoings, especially thanks to cryptocurrencies. 5.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. 5.1.8 Cyberwar This last kind of attack is certainly the less mediatised but without doubts 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 cyberwar: the stuxnet worm. 16

📄 Page 19

Figure 5.1: Phases of an attack 5.2 Phases of an attack 5.2.1 Reconnaissance The first phase consists of gathering at most information as possible about the target. Whether it be the names of the employees, the numbers of internet facing machines, 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 example). 5.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). 5.2.3 Lateral Movements Also known as pivoting, lateral movement designates the process of maintain- ing access and gaining access to more resources. Implants and various other tools are used during this phase. The biggest challenge is to stay unnoticed as long as possible. 5.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. 17

📄 Page 20

5.2.5 Clean up Once the attack is successfully completed, an advised attacker will cover his tracks in order to reduce the risk of being identified: logs, temporary files, infrastructure, phishing websites… 5.3 Profiles of attackers The profile of attackers is extremely varied. From lone wolves to teams of hackers, developers and analysts, there is definitely no standard profile that fits them all. However, in this section I will try to portray what kind of profiles should be part of a team conducting offensive operations. 5.3.1 The hacker The term hacker is controversial, mainstream media use it to describe crim- inals while tech people use it to describe passionate or hobbyists. 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. 5.3.2 The exploit writer The exploit writers are often developers with a deep understanding of se- curity. Their role is to craft the weapons used by his team to break into the target’s networks and machines. Exploit development is also known as “weaponization”. There are entire companies operating in grey waters dedi- cated to exploits trading, such as Vupen or Zerodium. 5.3.3 The developer The role of the developer is to build the tools 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. 18