Messing with binary formats
5 likes16,406 views
a 44CON 2013 presentation slides downloadable (including inception binary) at http://mix.corkami.com
![%PDF*****
1 0 obj
<<
/Size 2
/W[[]1/]
/Root 1 0 R
/Pages<<
/Kids[<<
/Contents<<>>
stream
BT{99
Tf{Td(Inlined PDF)'
endstream
>>]
>>
>>
stream
*
endstream
startxref%*******](https://image.slidesharecdn.com/44con2013-messingwithbinaryformat-130916110834-phpapp01/85/Messing-with-binary-formats-46-320.jpg)
![like washing powders
security tools are selected:
● speed
● {files} → {[clean/detected]}
file types not taken into consideration](https://image.slidesharecdn.com/44con2013-messingwithbinaryformat-130916110834-phpapp01/85/Messing-with-binary-formats-56-320.jpg)
More Related Content
What's hot (16)
Viewers also liked (6)
Similar to Messing with binary formats (20)
More from Ange Albertini (20)
Recently uploaded (20)
Messing with binary formats
- 1. Messing with binary formats London, EnglandAnge Albertini 2013/09/13 ΠΟΛΎΓΛΩΣΣΟΣ
- 2. Welcome! ● this is the non-live version of my slides ○ more text ○ standard PDF file ;) About me: ● Reverse engineer ● my website: http://corkami.com ○ reverse engineering & visual documentations to extract the live deck. 61 slides: pdftk 44con-albertini.pdf cat 1 3 5 7 9 10 12 14 16 18 23 25 29 31 33 35 37 39 41 43 45 47 49 51 53 55-57 59 63 65 67 69 71 73 75 77 79 81 83 85 87 89 90 94 96 98 101-102 104 106-107 109-112 114-117 119 output 44con-albertini(live).pdf 119 2 4 6 8 11 13 15 17 19+4 24 26+3 32 34 36 38 40 42 44 46 48 50 52 54 58 60+3 64 66 68 70 72 74 76 78 80 82 84 86 88 91+3 95 97 99+2 103 105 108 113 118
- 3. low-level ones, that is I just like to play with lego blocks
- 4. generate files byte per byte Goals ● explore the format ● make sure that's how things work ● full control over the structure
- 5. result: ● a complete executable ● all bytes defined by hand
- 6. our problem ● is related to virus (malwares) ● they use many file formats ● it's critical to identify them reliably ○ and to tell whether corrupted or well-formed
- 7. standard infection chain the most common chain: 1. a web page, in HTML format a. launching an applet 2. an evil applet, in CLASS format a. exploiting a Java vulnerability b. dropping an executable 3. a malicious executable, in Portable Executable format (a vast majority of malwares rely on an executable)
- 8. another classic chain ● open a PDF document ○ with an exploit inside ■ dropping or downloading a PE executable ● get a malicious executable on your machine
- 9. the challenge it might look obvious: ● tell whether it's a PDF, a PE, a JAVA, an HTML... ● typical formats are clearly defined ○ Magic signature enforced at offset 0
- 10. reality some formats have no header at all ● Command File (DOS 16 bits) ● Master Boot record some formats don't need to start at offset 0 ● Archives (Zips, Rars...) ● HTML ○ but text-only? some formats accept a large controllable block early in their header ● Portable Executable ● PICT image
- 11. How did this start? a real-life problem: 1. a (malicious) HTML page 2. started with 'MZ' (the signature of PE) 3. just scanned as a PE! a. wow, this PE is highly corrupted :) b. it must be clean :p ? MZ
- 12. polyglots in the wild GIFAR = GIF + JAR ● an uploaded image ○ an avatar in a forum ● with a malicious JAVA appended as JAR hosted on the server! ● bypass same domain policy ● now useable via its JAVA=EVIL payload + =
- 13. let's get started PE, the executable format of windows ● it's central to windows malware ● it enforces a magic signature at offset 0 ○ game over for other formats?
- 14. ● starts with a compulsory header ● made of sub-headers overview
- 15. a historical sandwich 1. a deprecated but required header 2. a modern header
- 16. old header content ● almost completely ignored ● only required: ○ 2 byte signature ○ pointer to new header
- 17. the new header can be anywhere ex: at the end of the file! such as Corkami Standard Test
- 18. let's look at HTML format
- 19. it enforces NOTHING! anything before the <html> tag! even 28 Mb of binary!
- 20. and it's been the same since Mozilla 1.0 in 2002thanks to Nicolas Grégoire!
- 21. now, the PDF format
- 22. signature position? ● officially at offset 0 ● officially tolerated until offset 1024 ● wtf? ○ it get actually worse later
- 23. PDF trick 1 put a small executable within 1024 bytes (just concatenate)
- 24. trick 2 1. start a fake PDF + object in a PE header 2. finish fake object at the end the PE 3. end fake object 4. put PDF real structure works with real-life example! (PE data might contain PDF keywords)
- 25. JAR = ZIP + Class just enforced at the very end of the file
- 26. but CRCs are just ignored it was too easy :p
- 27. Summary
- 28. Structure 1. start ○ PE Signature ■ %PDF + fake obj start ■ HTML comment start 2. next ○ PE (next) ○ HTML ○ PDF (next) 3. bottom ○ ZIP
- 29. it’s time for a real example! an inception demo! wait, what?
- 30. we’re already in the demo! the live version file is simultaneously: ● the PDF slides themselves ● a PDF viewer executable ○ ie, the file is loading itself ● the PoCs in a ZIP ● an HTML readme ○ with JavaScript mario
- 31. so, it works but it lacks something ● not artistic enough ● not advanced enough let's build a 'well representative' (=nasty) PoC
- 32. the PE specs ● Official MS specs = big joke ○ 'the gentle guide for beginners' ○ barely describes standard PEs
- 33. stripped down PE many elements removed ● including no sections
- 34. imports (imports = communication between executables and libraries) imports are made of 3 lists
- 35. evil imports ● let's make these lists into each other ● with more extra tricks to fail parser!
- 36. ultimate import fail ● failing all tools ○ including IDA & Hiew ● now fixed :)
- 37. let's put some code ● some undocumented opcodes! ● big blank spaces in Intel official docs
- 38. let's check AMD's ● miracle!
- 39. result in WinDbg ● '???' == clueless (tool/user) don't rely (only) on official docs
- 40. messing with PDF
- 41. there is a so-called standard and the reality of existing parsers looking at: Adobe, MuPDF, Chrome ● 3 different files ○ working each on a specific viewer ○ failing on the other 2
- 43. let's look inside ● MuPDF ○ no %PDF sig required ■ a PDF without a PDF sig ? WTF ?!?! ○ no trailer keyword required either ● Chrome ○ integer overflows: -4294967275 = 21 ○ trailer in a comment ■ it can actually be almost ANYWHERE ■ even inside another object ● Adobe ○ looks almost sane compare to the other 2
- 45. Chrome insanity++ (thx to Jonas Magazinius) ● a single object ● no 'trailer' ● inline stream ● brackets are not even closed ● * are required - it just checks for minimum space
- 46. %PDF***** 1 0 obj << /Size 2 /W[[]1/] /Root 1 0 R /Pages<< /Kids[<< /Contents<<>> stream BT{99 Tf{Td(Inlined PDF)' endstream >>] >> >> stream * endstream startxref%*******
- 47. PDF.JS ● very strict ○ 'too' strict / naive ? ○ I don't want to be their QA ;) ● requires a lot of information usually ignored ○ xref ○ /Length %PDF-1.1 1 0 obj << % /Type /Catalog ... >> endobj 2 0 obj << /Type /Pages ... >> endobj 3 0 obj << /Type /Page /Resources << /Font << /F1 << /Type /Font /Subtype /Type1 ... >> >> >> >> endobj 4 0 obj << /Length 47>> stream ... xref 0 1 0000000000 65535 f 0000000010 00000 n ...
- 48. let's play further combine 3 documents in a single file ● it's actually 3 set of 'independant' objects ● objects are parsed ○ but not used
- 49. alternate reality demo the live slide-deck contains 2 PDF ● bogus one under Chrome ● real one under MuPDF (Sumatra, Linux...) ● rejected under Acrobat ○ because of the PE signature (see later) DEMO
- 50. final PoC ● combine most previously mentioned tricks ● many fails on many tools ● total control of the structure ○ the PDF 'ends' in the Java class
- 51. Adobe rejects 'weird magics' after 10.1.5 not in their own specs :p 10.1.4 10.1.5
- 52. also in ELF/Linux flavor ● starring a signature-less PDF ○ which won't run on other viewers
- 54. and Apple too PS: I don't have a Mac, this was built blindly Thanks to Nicolas Seriot for testing
- 55. why should we care?
- 56. like washing powders security tools are selected: ● speed ● {files} → {[clean/detected]} file types not taken into consideration
- 57. type confusion make the tool believe it's another type, which will fool the engine engine with checksum caching will be fooled: 1. scanned as HTML, clean 2. reused as PE but malicious
- 59. engine exhaustion rankings in magazines are based on scanning time → scanning per file must stop arbitrarily → waste scanning cycle by adding extra formats
- 60. Weaknesses ● evasion ○ filters → exfiltration ○ same origin policy ○ detection ■ ex: clean PE but malicious PDF/HTML/... ■ exhaust checks ■ pretend to be corrupt ● DoS
- 61. Conclusion
- 62. Conclusion ● type confusion is bad ○ succinct docs too ○ lazy softwares as well ● go beyond the specs ○ Adobe: good ● suggestions ○ more extensions checks ○ isolate downloaded files ○ enforce magic signature at offset 0
- 63. Questions ? thank YOU !
- 65. Bonus
- 66. Valid image as JavaScript Highlighted by Saumil Shah ● abusing header and parsers laxisms ● turn a field into /* ● close comment after the picture data