Why bother? Default configurations Buffer overflows Authentication mechanisms Reverse engineering Questions?

Size: px

Start display at page:

Download "Why bother? Default configurations Buffer overflows Authentication mechanisms Reverse engineering Questions?"

Shannon Cox
6 years ago
Views:

1 Jeroen van Beek 1

2 Why bother? Default configurations Buffer overflows Authentication mechanisms Reverse engineering Questions? 2

3 Inadequate OS and application security: Data abuse Stolen information Bandwidth abuse (botnets) Host illegal media DDoS Legal issues White house hacked with on of your IPs You are responsible! 3

4 4

6 Many application protect sensitive information In the end protected by an authentication token Today mostly account + password A chain is as strong as it s weakest link Default passwords Password reset procedures Some real-life examples 6

7 Just a cheap internet router 7

8 Just a global ERP software vendor 8

9 Just a global network equipment vendor 9

10 Just a nuclear missle 10

11 loenix:/tmp# cat pass.c #include <iostream> #include <string> using namespace std; int main () { string secret = "really_c0mpl3x_passw0rd!", user = ""; cout << "Please enter the password: "; cin >> user; if(secret.compare(user)!= 0) cout << "wrong password\n"; else cout << "welcome!\n"; return 0; } loenix:/tmp# g++ pass.c -o pass loenix:/tmp# strings pass /lib/ld-linux.so [^_] really_c0mpl3x_passw0rd! Please enter the password: wrong password welcome! 11

12 Detection: Compile a list of default passwords of all applications Put the list in your IDS Lots of false positives (e.g. web page containing example /etc/shadow), false negatives (e.g. encryption) Prevention: Perform source code reviews (if possible) Use application baseline standards 12

13 One of the most abused software flaws Caused by improper bounds checking Writing >n or more bytes to a n bytes buffer Typically a C / C++ problem In many cases exploitable Overwrite memory Overwrite stack / heap with jump to malicious code Create account Open shell 13

14 cat overflow.c #include <iostream> using namespace std; int main () { char c[12]; // 11 characters + 0x00 cout << "What would you like me to echo? "; cin >> c; cout << "You said: " << c << "\n"; return 0; } bofh@tunnel:~/ot$./overflow What would you like me to echo? hello You said: hello bofh@tunnel:~/ot$./overflow What would you like me to echo? aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa You said: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa Segmentation fault bofh@tunnel:~/ot$ 14

15 15

16 Detection (more or less): Static source code analysis Fuzzing Prevention (more or less): Programming language: Try to avoid C and C++ for security-critical applications If possible Use trusted secure libraries (and keep them up-to-date!): A vulnerable library might also affect your safe code! ASLR NX Use secure coding standards 16

17 Address Space Layout Randomization Buffer overflows are exploited by shell code Shell code typically uses system calls System calls, stack, heap, libraries are located on fixed positions ASLR places them at random locations Shell code calls wrong addresses Crash (== secure) Enabled on recent OSs in some form: Windows: Vista+: full ASLR by default Linux: 2.6+: weak ASLR by default, distro specific OS X 10.8+: full ASLR by default Creating a reliable exploit is more difficult Not impossible! 17

18 ASLR needs to be used to be effective Example for Linux: OS + apache2 + mysql + php5 +sshd (PIE = Position Independant Executable) Similar for other Oss OT project? 18

19 No execute Buffer overflows are exploited by shell code Shell code often executes code in data memory NX prevent execution of code from data memory Shell code is not executed Enabled on recent OSs in some form: Windows: XP SP2+: DEP by default Linux 2.6+: depend on distribution and version OS X 10.5+: W^X on stack and heap by default Creating a reliable exploit is more difficult Not impossible! 19

20 Write random value before stack return pointer Check value on return Buffer overflow exploit overwrites value alert Creating a reliable exploit is more difficult Not impossible! 20

22 In many cases authentication mechanisms are: Closed source Based on proprietary protocols Backward compatible with older versions Not using key / hash diversification Poorly tested Important risks: Authentication bypass Reduced key entropy Decode / crack complex passwords 22

24 Well-known example: MS LanManager (LM): Really 0ldskewl: OS/2 & MS-DOS era Enabled by default until Windows Vista For all passwords < 15 positions Backward compatibility What s the problem? 24

25 Password complexity: Character set ^ length 14 position password using [a-z][a-z][0-9] 62 ^ 14 = giga combinations Brute force cracking takes forever LAN manager 14 position password using [A-Z][0-9] Divides the password in two 7 position parts Uppercase only 36 ^ 7 = 78 gig combinations Brute force cracking takes hours 25

26 If a password hash is the same on every system, you can pre-calculate hashes Large look-up table The art is perfected: rainbow tables Time versus storage trade-off Crack complex passwords within minutes Free tables for LM, NTLM, MD5, SHA-1, GPU based cracking 26

27 Detection: Detect known downgrade attacks Besides that quite difficult Prevention: Review the used algorithms before using them If possible Use proven open standards Use salting Do not use: hash(password) Instead use: random + hash(password + random) Attack time will grow (depending on number of salts used) Generic rainbow tables won t work anymore 27

28 Program flow manipulation: Skip / manipulate checks: Games Password checks Bank transfer integrity checks Static: Change the file on disk E.g. IDA Pro Dynamic: Don t change the file on disk Change program flow in run-time E.g. OllyDbg 28

29 Attacks on SWIFT environments o-bytes-to-951m.html 29

30 Example bypassing a security check In then end it s just a 0 or a 1 In this case: Boolean expression Let s swap yes and no! OllyDbg 30

31 Detection: Static analysis: none? Dynamic analysis: check for debuggers Cat and mouse game Application patches (cracks, backdoors, ): Application whitelisting: verify checksums: Windows AppLocker, SELinux Look for changes (good or bad): Prevention: Application signing Obfuscate / encrypt the application code Only slows an attacker down! 31

32 32

34 J.C.vanBeek uva.nl 34

Why bother? Default configurations Buffer overflows Authentication mechanisms Reverse engineering Questions?

Jeroen van Beek 1 Why bother? Default configurations Buffer overflows Authentication mechanisms Reverse engineering Questions? 2 Inadequate OS and application security: Data abuse Stolen information Bandwidth